perm filename SIMLIB.MAN[UP,DOC] blob
sn#462230 filedate 1979-07-27 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00060 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00009 00002
C00013 00003 DECsystem-10 SIMULA Language Handbook, part III Page 2
C00017 00004 DECsystem-10 SIMULA Language Handbook, part III Page 3
C00021 00005 DECsystem-10 SIMULA Language Handbook, part III Page 4
C00024 00006 DECsystem-10 SIMULA Language Handbook, part III Page 5
C00028 00007 DECsystem-10 SIMULA Language Handbook, part III Page 6
C00032 00008 DECsystem-10 SIMULA Language Handbook, part III Page 7
C00037 00009 DECsystem-10 SIMULA Language Handbook, part III Page 8
C00041 00010 DECsystem-10 SIMULA Language Handbook, part III Page 9
C00045 00011 DECsystem-10 SIMULA Language Handbook, part III Page 10
C00050 00012 DECsystem-10 SIMULA Language Handbook, part III Page 11
C00055 00013 DECsystem-10 SIMULA Language Handbook, part III Page 12
C00059 00014 DECsystem-10 SIMULA Language Handbook, part III Page 13
C00063 00015 DECsystem-10 SIMULA Language Handbook, part III Page 14
C00066 00016 DECsystem-10 SIMULA Language Handbook, part III Page 15
C00070 00017 DECsystem-10 SIMULA Language Handbook, part III Page 16
C00074 00018 DECsystem-10 SIMULA Language Handbook, part III Page 17
C00078 00019 DECsystem-10 SIMULA Language Handbook, part III Page 18
C00082 00020 DECsystem-10 SIMULA Language Handbook, part III Page 19
C00086 00021 DECsystem-10 SIMULA Language Handbook, part III Page 20
C00090 00022 DECsystem-10 SIMULA Language Handbook, part III Page 21
C00094 00023 DECsystem-10 SIMULA Language Handbook, part III Page 22
C00097 00024 DECsystem-10 SIMULA Language Handbook, part III Page 23
C00100 00025 DECsystem-10 SIMULA Language Handbook, part III Page 24
C00102 00026 DECsystem-10 SIMULA Language Handbook, part III Page 25
C00106 00027 DECsystem-10 SIMULA Language Handbook, part III Page 26
C00107 00028 DECsystem-10 SIMULA Language Handbook, part III Page 27
C00110 00029 DECsystem-10 SIMULA Language Handbook, part III Page 28
C00112 00030 DECsystem-10 SIMULA Language Handbook, part III Page 29
C00115 00031 DECsystem-10 SIMULA Language Handbook, part III Page 30
C00118 00032 DECsystem-10 SIMULA Language Handbook, part III Page 31
C00122 00033 DECsystem-10 SIMULA Language Handbook, part III Page 32
C00126 00034 DECsystem-10 SIMULA Language Handbook, part III Page 33
C00131 00035 DECsystem-10 SIMULA Language Handbook, part III Page 34
C00134 00036 DECsystem-10 SIMULA Language Handbook, part III Page 35
C00137 00037 DECsystem-10 SIMULA Language Handbook, part III Page 36
C00140 00038 DECsystem-10 SIMULA Language Handbook, part III Page 37
C00143 00039 DECsystem-10 SIMULA Language Handbook, part III Page 38
C00147 00040 DECsystem-10 SIMULA Language Handbook, part III Page 39
C00151 00041 DECsystem-10 SIMULA Language Handbook, part III Page 40
C00154 00042 DECsystem-10 SIMULA Language Handbook, part III Page 41
C00158 00043 DECsystem-10 SIMULA Language Handbook, part III Page 42
C00161 00044 DECsystem-10 SIMULA Language Handbook, part III Page 43
C00164 00045 DECsystem-10 SIMULA Language Handbook, part III Page 44
C00167 00046 DECsystem-10 SIMULA Language Handbook, part III Page 45
C00171 00047 DECsystem-10 SIMULA Language Handbook, part III Page 46
C00175 00048 DECsystem-10 SIMULA Language Handbook, part III Page 47
C00180 00049 DECsystem-10 SIMULA Language Handbook, part III Page 48
C00185 00050 DECsystem-10 SIMULA Language Handbook, part III Page 49
C00190 00051 DECsystem-10 SIMULA Language Handbook, part III Page 50
C00195 00052 DECsystem-10 SIMULA Language Handbook, part III Page 51
C00199 00053 DECsystem-10 SIMULA Language Handbook, part III Page 52
C00203 00054 DECsystem-10 SIMULA Language Handbook, part III Page 53
C00206 00055 DECsystem-10 SIMULA Language Handbook, part III Page 54
C00210 00056 DECsystem-10 SIMULA Language Handbook, part III Page 55
C00214 00057 DECsystem-10 SIMULA Language Handbook, part III Page 56
C00219 00058 DECsystem-10 SIMULA Language Handbook, part III Page 57
C00223 00059 DECsystem-10 SIMULA Language Handbook, part III Page 58
C00226 00060 DECsystem-10 SIMULA Language Handbook, part III Page 59
C00228 ENDMK
C⊗;
Swedish National Defense Research Institute FOA Rapport
Department of Planning and Operations Research C10045-M3(E5)
S-10450 Stockholm 80 PRELIMINARY
EDITION:
Februari 1976
DECsystem-10 SIMULA Language Handbook Part III
==============================================
(The DECsystem-10 SIMULA Utility Program Library)
BY Stefan Arnborg, Karel Babcicky, Lars Enderin, Mats Ohlin,
Stephan Oldgren and Jacob Palme.
ABSTRACT:
The DECsystem-10 SIMULA Language Handbook contains the
information necessary for an applications programmer who
intends to use SIMULA on a DECsystem-10 computer.
Part I contains a description of the SIMULA programming
language. Part II contains special information for
DECsystem-10. Part III describes the utility program library,
which includes:
> An improved version of the SAFEIO package for safe
conversational terminal interface.
> Utility routines for inserting a help facility into the
conversational terminal communication, where the appropriate
help message at each point in the program can be selected from
a file containing several messages.
> Routines for accessing date, time etc.
> Routines to allow the writing of real-time programs in SIMULA
(e.g. programs which can communicate simultaneously with more
than one user terminal.)
> Routines for binary (un-formatted) i/o.
> Routines for record-oriented i/o.
> Routines for file handling.
> A utility package of routines for character string (TEXT)
handling, with routines for searching, splitting,
concatenating, hashing etc. on TEXTs.
> Routines for in-core sorting and summation.
This document reflects the software as of version 3 of the
DECsystem-10 SIMULA system.
Last update 1976-03-01.
DECsystem-10 SIMULA Language Handbook, part III Page 2
SEARCH KEY
Computer, Programming, Programming Language, SIMULA,
DECsystem-10, Digital Equipment, Algol 60, Fortran, Program
library, file handling, input/output, conversational
programming, real time, error handling, string handling,
character handling, text handling, sorting.
CONDITIONS OF RELEASE
The information in this document is subject to change
without notice. The Swedish National Defence Research
Institute assumes no responsibility for any errors that may
appear in this manual, in the programs described therein or
in the SIMULA system itself. No promise is made to
implement any of these programs, especially not those marked
"NOT READY".
The software described in this document is furnished to the
user for use on a DECsystem-10 computer system and may be
copied only for use on such systems, except as may otherwise
be provided in writing by the Swedish National Defence
Research Institute.
ACKNOWLEDGEMENT
Part of this document has been adapted from the similar text
for the IBM 360/370 SIMULA System, written by Karel Babcicky
at the Norwegian Computing Center.
Copyright 1976 by The Swedish National Defense Research
Institute and (partly) The Norwegian Computing Center.
SOME OF THE PROCEDURES ARE NOT YET WRITTEN
This preliminary version of part III of the handbook
contains certain procedures which have not yet been written.
The description of them are only proposals, and we may never
implement them or we may implement them in another way than
described here.
These procedures are marked [NOT READY] in section 0.2 but
they are not always marked [NOT READY] in the following
chapters. Always refer to section 0.2 to check if a
procedure is available. Copying is allowed for use with the
DECsystem-10 computer.
DECsystem-10 SIMULA Language Handbook, part III Page 3
0. INTRODUCTION
----------------
The intention is to include in this library utility programs
of general interest to users of SIMULA on the DECsystem-10.
Examples:
> Programs for editing and generating SIMULA source programs.
> Useful program packages written in SIMULA such as data base
packages, graphic packages, conversational i/o packages.
> Useful MACRO 10 programs to be called from SIMULA, e.g. for
object and binary i/o, access to monitor facilities like the
clock.
The programs in the library will be distributed to
DECsystem-10 users through the DECUS library, either as
separate programs or on the SIMULA distribution tape.
Anyone who has submitted a program to the DECUS library,
such that the program is also suitable for inclusion in the
SIMULA program library, is invited to send us a copy of the
program and its documentation. If we accept the program, we
will include its description in future releases of this
handbook.
0.1 HOW TO GET ACCESS TO PROGRAMS IN THE LIBRARY
Most of the routines in this library are available in the
library files LIBSIM.ATR and LIBSIM.REL. These files should
normally be available in the SYS: area on your computer, but
you can also keep them on your own disk area. Routines
which are main programs to be executed directly are normally
available as separate .SAV files, not kept in the LIBSIM
libraries.
The routines are loaded from SYS:LIBSIM and thus available
in your program if you declare them as external at the
beginning of your program, e.g.
EXTERNAL CLASS safeio;
EXTERNAL PROCEDURE hash;
You need not mention any explicit filename if you are using
routines in LIBSIM on the SYS area or on your own area. An
external declaration in a separately compiled segment must
be repeated in all dependent separately compiled segment
including the main program.
For accessing routines on other libraries, see the
DECsystem-10 SIMULA Language Handbook part II chapter 7.1.1.
When you load your programs with the "LOAD", "EXECUTE" or
DECsystem-10 SIMULA Language Handbook, part III Page 4
"DEBUG" command of DECsystem-10, you need not mention these
separately compiled classes or procedures. Just write:
.EXECUTE myprog
if your program has the name myprog. Any external classes
or procedures declared as such inside myprog will
automatically be loaded.
If you cannot find the necessary .SIM, .REL, .ATR, .HLP,
.MAN or .DOC files on the SYS:, HLP: or DOC: areas on your
computer, they may still be found on the SIMULA distribution
tape. REL and ATR files for separately compiled procedures
or classes can be found in the libraries LIBSIM.ATR and
LIBSIM.REL on the SYS: area.
The source code and documentation files (.HLP, .MAN, .DOC,
.RNH, .RNM, .RND files) for the programs described in this
handbook can usually be found in the large packed file
LIBSIM.PAC.
For routines written in MACRO-10, there is usually no
separate .SIM specification file. Instead, the .MAC file is
written such that when you compile it with the SIMULA
compiler, you get the necessary .ATR file produced.
Individual files can be unpacked from this file by running
the program FILPAC.SAV.
Before running FILPAC you must sometimes give the command
.assign DSKD DSK
Input from the terminal to the FILPAC program should end
with ALTMODE.
In addition to the programs listed below, a SIMULA
programmer has access to a number of built-in standard
functions. These are described in appendix B to the
DECsystem-10 SIMULA Language Handbook part I.
DECsystem-10 SIMULA Language Handbook, part III Page 5
0.2 SUMMARY LIST OF ROUTINES
0.2 SUMMARY LIST OF ROUTINES
Letter codes in this list:
..=repetition of parameter, R=REAL, L=LONG REAL, I=INTEGER,
C=CHARACTER, T=TEXT, X=REF, B=BOOLEAN, G=LABEL, a=ARRAY,
P=PROCEDURE, K=CLASS, M=MAIN PROGRAM.
The first column for each program indicates type of result for
function procedures, K for separately compiled classes, M for
main programs(not in LIBSIM). The following letters indicate
parameter types.
1. UTILITY PACKAGES:
K T,T SAFEIO Safe conversational terminal i/o. See
SAFEIO.HLP and SAFEIO.MAN
K T SAFEI SAFEIO without file handling facilities
K SAFMIN Small, simplified version of SAFEI
K T,T SIMEIO Same as SAFEIO but prefixed with
SIMULATION
K T SIMEI Same as SAFEI but prefixed with
SIMULATION
K SIMMIN Same as SAFMIN but prefixed with
SIMULATION
K SIMDBM CODASYL DBTG type DBMS system. Consists
of the external classes DBMTXT, DBM,
DBMSET and the main programs FETCH,
LOAD, DIRED, SPEC and PREP
K I,I STORE Simple text-oriented DBMS
K SELECT Boolean condition searching TEXT or FILE
K FIGURE Plot package for Tektronix plotter.
GRAPHI, COSYS, COSYSF and RUBOUT are
also part of this package. See
FIGURE.HLP.
K I,I,X,B,I VISTA Full control of infoton vista terminal
display screen, e.g. to produce moving
pictures
K T DAHELP Give user help message when running
SIMULA program. Uses direct-access file
to store help messages. See DAHELP.HLP
B T,T,I,I SQHELP Give user help message when running
SIMULA program. Uses sequential file to
store help messages
K I DECOM (Subclass to SAFMIN) Interpret input
command of the format
outfil.ext/switch1/switch2...
=infil.ext/switch3/switch4...
M SIMDEM SIMULA demonstration programs
DECsystem-10 SIMULA Language Handbook, part III Page 6
0.2 SUMMARY LIST OF ROUTINES
2. SIMULA SOURCE CODE CONVERSION PROGRAMS:
[These are main programs, and thus not
placed in LIBSIM]
M SIMED Prettyprinting, cleaner layout,
indentation of BEGIN-END, no semantic
change of program
M SIMSTR [NOT READY] Automatic structure abstract
of source program
M SIMEXP Combines separately compiled modules
into one module
M SIMIBM Conversion to IBM Simula
M IBMSIM Conversion from IBM Simula
M CDCSIM Conversion from CDC Simula
M FQCRED Adds frequency count statements to a
SIMULA program
M FQCLST Edits SIMULA source program with
frequency measurements
3. DIRECTFILE HANDLING PROGRAMS
M DIRED Edits a directfile
M MAKEDF Produce a directfile from a sequential
file
M FETCH General-purpose SIMDBM Data Base
Manipulator
M MAKHLP Create help file for use with DAHELP
4. PROCEDURES NOT WRITEABLE IN SIMULA:
4.1 TIME AND DATE
T TODAY Give TEXT with date: yyyy-mm-dd
I DAYNO Number of this day in current year
T DAYTIME Give TEXT with hh:mm:ss
R CLOCKTIME Give REAL with time of day in seconds
R CPTIME Give LONG REAL with CPU time in seconds
? ? TIMELIMIT [NOT READY] Set time limit for current
execution
4.2 REAL TIME
[PRE-RELEASE VERSION]
B X INPUTCHECK Anything to read on file X?
P R SLEEP Delay execution for R real seconds
I Xa,R INPUTWAIT Sleep until anything to read
K REALTIME Scheduler for terminal processes
DECsystem-10 SIMULA Language Handbook, part III Page 7
0.2 SUMMARY LIST OF ROUTINES
4.3 INPUT/OUTPUT
I X LINECOUNT Return LINESPERPAGE setting
I X FILENAME Give TEXT with FILE object generation
parameter
C GETCH Input character, do not wait for
carriage return (input from controlling
terminal only)
C X INSINGLECHAR [NOT READY] Input character, do not wait
for carriage return (Input from any
connected TTY)
P ILRCPa.. READ Read many values in standard format
P ILRCTPa.. WRITE Write many values in standard format
I X,RLICBTXa.. OUTPUT Binary output
I X,RLICBTXa.. INPUT Binary input
I RLICBTXa.. PUTSIZE How much will OUTPUT write?
B X,I BYPASS [NOT READY] Bypass I characters in a
file
B X,LRIC LOOK [NOT READY] Binary one-word lookahead in
input
B T SCRATCHFILE Delete file on secondary storage
X T FINDINFILE NEW INFILE, but no error if file does
not exist
X T,B FINDDIRECTFILE NEW DIRECTFILE but no error if not found
or not updateable
X T FINDOUTFILE NEW OUTFILE, but no error if write
protected
X T FINDPRINTFILE NEW PRINTFILE, but no error if write
protected
I X LASTLOC Highest written line in a DIRECTFILE
I X MAXLOC [NOT READY] Highest writeable line in a
DIRECTFILE
P X CLOSEOPEN [NOT READY] Close and immediately open a
file
P X DOTYPEOUT Reset CTRL-O bit to resume terminal
output
I I,X,I TRMOP Modify monitor-terminal interface
B NUMBERED Did last inimage get a line-numbered
line?
P X,I ECHO Suppress monitor echoing of terminal
input
T T TMPNAM Create a temporary file name like
"021SIM.TMP"
4.4 CONTROLLED ERROR HANDLING
P I,I MASKERROR [NOT READY] Continue for certain kind of
forthcoming error
P I,G JUMPERROR [NOT READY] Goto label for certain kind
of forthcoming error
I I SENSEERROR [NOT READY] How many masked errors have
DECsystem-10 SIMULA Language Handbook, part III Page 8
0.2 SUMMARY LIST OF ROUTINES
occurred
P I RESETERROR [NOT READY] Inhibit MASKERROR action
P B ENTERDEBUG Transfer to SIMULA debugging system
P T ABORT User program generated error interrupt
P I FORSIM Traps i/o calls from FORTRAN external
procedures
4.5 SCHEDULING
P B SUBMIT [NOT READY] Enter file into input batch
stream
P T,I RUN Run a new program under the current job
4.6.1 PRIMARY MEMORY HANDLING
I I FREEBITS [NOT READY] Force garbage collection,
return maximal free area size
4.6.2 VIRTUAL MEMORY CONTROL
B I COREGUIDE [NOT READY] Set physical guideline
B I CORELIMIT [NOT READY] Set physical limit
P XP.. SWAP [NOT READY] Swap out given module from
main store
4.7 SAVE-RESTORE FACILITY
[PRE-RELEASE VERSION]
I T,B SAVE Save current main memory on a file
P T RESTORE Resume execution from save file
P I FREEZE Exit to monitor with job ready to save
4.8 ENVIRONMENT ENQUIRY
I MAXINT Largest positive INTEGER
R MAXREAL Largest positive REAL
R MINREAL [NOT READY] Smallest positive REAL
R R ADDEPS [NOT READY] Smallest number greater than
argument
R R SUBEPS [NOT READY] Greatest number smaller than
argument
L L ADDLEPS [NOT READY] ADDEPS for LONG REAL
argument
L L SUBLEPS [NOT READY] SUBEPS for LONG REAL
argument
L LR,LR APPROX [NOT READY] Return integer value
corresponding to numbers of bits
differing in two arguments
T IMPLEMENTATION [NOT READY] CPU manufacturer and model
T LOGINFO [NOT READY] Project number etc.
I a DIMENSIONS [NOT READY] Number of dimensions
DECsystem-10 SIMULA Language Handbook, part III Page 9
0.2 SUMMARY LIST OF ROUTINES
(subscripts) of ARRAY
4.9 PACKING INTO PARTS OF WORDS
B IRLa,I,IRLCBTa,I,.. PACK Pack many variables of varying type
(not REF)
B IRLa,I,IRLCBTa,I,.. UNPACK Reverse of pack
4.10 MIN AND MAX
I Ia.. IMIN | [NOT READY] Varying number of
I Ia.. IMAX | parameters. INTEGERs, REALs,
| LONG REALs, ARRAYs
LR LRa.. RMIN | IMIN and IMAX return INTEGER results
LR LRa.. RMAX | RMIN and RMAX return [LONG] REAL
| results
I Ia ILIND | [NOT READY] Find G(reatest) or
I Ia IGIND | L(east) argument in an array.
R Ra RLIND | Return index for the first argument
R Ra RGIND | which is
L La LLIND | >= (G) or <= (L) all other elements.
L La LGIND | x is I(nteger array), R(eal array),
T Ta TLIND | L(ong real array) or T(ext array).
T Ta TGIND |
5. PROCEDURES (ALMOST) WRITEABLE IN SIMULA:
5.1 PARTITIONING OF TEXTS
T T REST Subtext after POS
T T FRONT Subtext before POS
T T,I FROM Subtext after argument position
T T,I UPTO Subtext before argument position
T T FRONTSTRIP Subtext without leading blanks
T T GETITEM Subtext = next identifier, number or
delimiter after POS
T X INITEM GETITEM on INFILE [NOT READY FOR
DIRECTFILES] or DIRECTFILE
C T,I FETCHAR Return indexed CHARACTER from a TEXT
P T,I,C DEPCHAR Deposit a character at indicated
position
T T,I,I TSUB Perform SUB returning NOTEXT instead of
error
DECsystem-10 SIMULA Language Handbook, part III Page 10
0.2 SUMMARY LIST OF ROUTINES
5.2 SEARCHING AND TESTING OF TEXTS
T T,C SCANTO Next occurrence of CHARACTER in TEXT
T C SKIP Skip all characters equal to argument
from pos and on
B T1,T2 FRONTCOMPARE Does rest of TEXT T1 begin with subtext
= T2?
B T1,T2 UPCOMPARE Same as FRONTCOMPARE, but upper and
lower case characters are regarded as
equal
T T1,T2 SEARCH Find first subtext = T2 after POS in T1
I T GETTYPE [NOT READY] Does a TEXT contain REAL,
INTEGER, IDENTFIER or what ITEM?
I T CHECKREAL Checks if GETREAL can be performed
I T CHECKINT Checks if GETINT can be performed
I T CHECKFRAC Checks if GETFRAC can be performed
I T,I HASH Compute hash value from text in interval
[0:I-1]
C T,T FINDTRIGGER Next occurrence of any character in a
given string
B T,I,Ta,I MENU Search for unambiguous text in a text
array
B T,Ta,I,I,I LOOKUP Perform binary search in sorted text
array
5.3 OPERATIONS ON TEXTS
T T,T CONC2 Concatenation of TEXTs, two parameters
T T.. CONC Concatenation of TEXTs, variable no. of
parameters
B T1,T2 PUTTEXT Copies value of T2 at POS in T1
T T UPCASE Convert lower case letters to upper case
T T LOWCASE Convert upper case letters to lower case
T C,I MAKETEXT NEW text with all I characters equal to
C
T T,C COMPRESS Remove given character from text
I T STARTPOS Return starting position for a (sub)text
P T,T,T,T SPLIT Split a text at given delimiter
I T,T,T,T SPLITA Split a text and store the parts in a
text array
B T,T,T CHANGE Replace old (sub)string with new string
in a master text
L T SCANREAL GETREAL but safe from bad data interrupt
I T SCANINT GETINT but safe from bad data interrupt
I T SCANFRAC GETFRAC but safe from bad data interrupt
I T,Ra,I GETARRAY [NOT READY] Reads from a text real
values into a REAL ARRAY
I T,Ia,I GETINTARRAY [NOT READY] Ditto INTEGER ARRAY
I T,Ra,I GETLONGARRAY [NOT READY] Ditto LONG REAL ARRAY
T T,T CHECKEXTENSION Add defaultextension if file spec
contains no dot
DECsystem-10 SIMULA Language Handbook, part III Page 11
0.2 SUMMARY LIST OF ROUTINES
5.4 INPUT/OUTPUT
C X LOOKAHEAD Next non-blank character readable by
INCHAR
P T,X OUTLINE [NOT READY] Output TEXT on new line(s),
TEXT may be longer than image
P T,X BREAKOUTLINE [NOT READY] Output TEXT on same line,
TEXT may be longer than image
T T,X INLINE Type out a prompting question and copy
an infile image (stripped)
P RCIX OUTTIME Converts simulated time to hh:mm:ss.cc
format and prints it on a given outfile
5.5 SORTING AND SUMMATION ETC.
I R ILOG Return integer part of 10LOG(|arg|)+1;
if 0 return 0. I.e. Number of integer
digits if |arg| >= 1 else number of
leading zeros after decimal point.
I Ia,I ISUM Return sum of an integer array
L La,I LSUM Return sum of long real array (almost)
preserving precision
R Ra,I RSUM Return sum of real array
R R,R,Ra,I SIGMA2 [NOT READY] Return variance, mean value
of a real array
P R,R,I,R SIGMEAN Return current variance and mean value
including new observation
P "x"a,I SORTxy Sort a given array in ascending or
descending order.
x = T(ext), R(eal), I(nteger) or L(ong
real)
y = A(scending), D(escending) order.
5.6 RANDOM NUMBER GENERATION ETC.
P Ia,I,I,I SCRAMBLE Random permutation of aray
R R,R RANDOM Random generator of random number series
start numbers
I UNIQUE Unique number to be used e.g. as start
random number
6. SWEDISH LANGUAGE TEXT PROCESSING AND INPUT/OUTPUT
B T,I,Ta,I MENY Swedish version of MENU
[Accept $, #, @ and ← as letters.]
B C BOKSTAV [NOT READY] Swedish version of LETTER
T T STORBOKSTAV [NOT READY] Swedish version of UPCASE
T T TAGORD [NOT READY] Swedish version of GETITEM
T X INORD [NOT READY] Swedish version if INITEM
I T TAGTYP [NOT READY] Swedish version of GETTYPE
DECsystem-10 SIMULA Language Handbook, part III Page 12
1. UTILITY PACKAGES
1. UTILITY PACKAGES
--------------------
**** SAFEIO is a package to enable a safe question-and-answer
dialogue with a conversational terminal. The programs in
the package allow you to ask the user for variables of
various SIMULA types. The user answers are checked for
correct type and for acceptance according to criteria
specified by the programmer. Help and error messages are
given. The package protects from error interrupts in
programs which may receive faulty input data from the user.
The user may save his input in a log file. This file can
later be used as input instead of the tty. Other files may
also be used as input, intermixed with tty input. SAFEIO is
distributed as the files SAFEIO.SIM, SAFMIN.SIM, SIMEIO.SIM,
SIMMIN.SIM, SAFEIO.RNM, SAFEIO.MAN, SAFEIO.NEW, SAFMIN.HLP,
SAFEIO.ENG, SAFEIO.SWE and SAFEIO.HLP.
Written by Mats Ohlin, Swedish National Defense Research
Institute.
SAFEIO
------
SAFEIO is a SIMULA external class which can be used when
writing the conversational parts of SIMULA programs.
The SAFEIO system offers the following facilities in a
single procedure call :
1. Issue a prompting question to the user.
2. Store the input in a simple variable.
3. Optionally accept default answers (equal to CR).
4. Check the syntax of the input.
5. Issue an appropriate message if the input is
invalid.
6. Issue an explanatory message if the user responds
with anything starting with a question mark '?'.
7. Allow the user to substitute tty input for disk file
input. This may be done at any time a question is
to be answered.
8. Allow the user to save all accepted program input on
a disk file. This file may be used as an input file
in a subsequent run. Correspondence between saved
and current question will be checked (option by
default).
DECsystem-10 SIMULA Language Handbook, part III Page 13
1. UTILITY PACKAGES
It is assumed that the user type only one item on each input
line.
A question to the user is defined by the call:
REQUEST("prompting
question",default,***input(variable,validity), " error
message if not valid",helpproc←expression);
The parameter default is a text variable or text constant
(or may be a call of a text procedure). There is a SAFEIO
attribute NODEFAULT which can be used if default answers
should be prohibited.
The *** may be INT,REAL,LONGREAL,BOOL or TEXT. For the
BOOLINPUT procedure there is only one argument though, the
receiving variable.
The validity is usually a boolean expression involving the
variable but may also be a call of a boolean procedure if
more complicated validity checking is necessary. If the
SAFFEIO attribute CHECKVALIDITY is set to FALSE, no validity
checking (i.e. no evaluation of the 2nd parameter to the
***input procedure) will occur, thus speeding up SAFEIO
execution. Note, however that this will endanger the
security of your program.
The error message is printed if the validity becomes FALSE.
The prompting question will then be repeated.
The helpproc←expression will be evaluated each time the user
types in an answer beginning with a questionmark '?'.
The SAFEIO boolean procedure HELP (with one text parameter =
the help text) may be used for displaying a text on the
user's TTY.
If no special information should be issued the SAFEIO
procedure NOHELP may be used. (The message - "There is no
help in this case." will be issued.)
Some examples:
BEGIN
EXTERNAL REF (Infile) PROCEDURE findinfile;
EXTERNAL REF (Outfile) PROCEDURE findoutfile;
EXTERNAL TEXT PROCEDURE conc,upcase,frontstrip,
rest,checkextension;
EXTERNAL CHARACTER PROCEDURE fetchar,findtrigger;
EXTERNAL LONG REAL PROCEDURE scanreal;
DECsystem-10 SIMULA Language Handbook, part III Page 14
1. UTILITY PACKAGES
EXTERNAL INTEGER PROCEDURE checkreal,checkint,
scanint,ilog;
EXTERNAL BOOLEAN PROCEDURE menu;
EXTERNAL CLASS safeio;
safeio(..<name of log file for input or "">,
<"English" or "Swedish">..)
! Use "English" if English texts are wanted.
Use "Swedish" if Swedish texts are wanted. ;
BEGIN
INTEGER i; REAL x; LONG REAL y;
TEXT t; BOOLEAN b;
TEXT ARRAY table[1:4];
request("Enter integer:","14",
intinput(i,irange(i,1,20)),
outofirange(i,1,20),
help("...info issued at '?'.."));
! The default value is 14. Only positive numbers
! are allowed.;
! Note the use of the procedures IRANGE(i,low,high)
! and OUTOFIRANGE(i,low,high).
! See also Summary Chapter 5 in SAFEIO.MAN.;
request("Enter real item:",nodefault,
realinput(x,TRUE),"",nohelp);
! Default answer not allowed. Any legal real item
! is accepted since validity is TRUE.
! No help information available.;
request("Enter long real value:","E1",
longrealinput(y,y NE 0),
"? Must not be zero.",nohelp);
! Default value is 10 = E1;
request("Enter yes or no:",nodefault,
boolinput(b),"",nohelp);
! Note that procedure boolinput has just one
! parameter.;
table[1]:- Copy("START");
table[2]:- Copy("END");
table[3]:- Copy("GO");
table[4]:- Copy("GOTO");
request("Enter command:",nodefault,
DECsystem-10 SIMULA Language Handbook, part III Page 15
1. UTILITY PACKAGES
textinput(t,menu(t,i,table,4)),
commandmessage(index),commandhelp(table,4));
! Note that the table must contain no lower case
! letters.
! The user may use an abbreviated form when no
! ambiguity exists.
! (Exact matches are always considered correct.)
! The variable i will return the table index.
! The length of the table (4) must also be supplied.
! Note that the table must contain upper case
! letters only.
! The procedure MENU resides in LIBSIM and checks
! for correspondence between the T and the table.;
! The text procedure commandmessage will tell the
! user if his (illegal) command was either
! Unknown or Ambiguous.
! A simple text request: ;
request("Enter A or B:","A",
textinput(t,t = "A" OR t = "B" OR
t = "a" OR t = "b"),
"? Answer A or B.",nohelp);
! The user may define his own boolean procedure for
! input validation if more complicated tests are
! necessary.;
GO TO start; ! Will restart from SAFEIO prefix;
! START is a SAFEIO label located
! just in front of INNER.;
! If the label EOF exists,
! End-of-file on SYSIN (=↑Z)
! will jump to this label. If EOF does not not exist
! in the user program, the SAFEIO block will
! terminate through an internal SAFEIO jump.
! NOTE! Once Sysin.Endfile is TRUE, there can be no
! more input on Sysin!. This mechanism will only
! work for blocks prefixed by SAFEIO
! (i.e. NOT when using NEW SAFEI(O)).;
END of SAFEIO block;
END of program;
On receiving any SAFEIO question on the terminal
the user may input one of the SAFEIO commands:
DECsystem-10 SIMULA Language Handbook, part III Page 16
1. UTILITY PACKAGES
? to get help information.
! FOLLOWED by:
* to change the switch: Display-prompting-question.
/ to change the switch: Display-default-value.
= to change the switch: Display-input (+ the *- and
/-switches).
[ to change the switch: Trace (file messages).
+ to close and reopens current recording file in
append mode.
; to treat line as a comment.
% to call special procedure. & followed by input to
override validity test. <FIL.EXT to open new
input file in wait mode. Default extension =.saf
to continue input in nowait mode.
< to close current input file.
↑ to close all active input files.
←FIL.EXT to open new input file in nowait mode. Default
extension =.saf
>FIL.EXT to open new recording file. Default extension
=.saf
> to close current recording file.
? to print this text.
Anything else following ! will cause current question to be
displayed.
The != command will always change the values of the switches
Display-prompting-question and Display-default-value to the
same value as the switch Display-input.
Note that the ! facility may be switched off by calling the
←
procedure NOOVERRIDE.
The !% facility gives the programmer the possibility to
declare his own procedure SPECIAL (with exactly that name
and without parameters) which will be called when the user
responds with !%. It is possible to interpret the
information following the !% in the procedure, thereby
expanding the power of the SAFEIO - ! commands. See
SAFEIO.MAN for further information on SAFEIO attributes.
If you are using SAFEIO via INSPECT it is not meaningful to
specify any initial recording file, since it will be closed
immediately. This is because the INNER in SAFEIO will be
passed. In order to close all possible open SAFEIO files,
end the connection block with a call of the SAFEIO procedure
closefiles. I.e. :
BEGIN EXTERNAL declarations.....;
DECsystem-10 SIMULA Language Handbook, part III Page 17
1. UTILITY PACKAGES
....
INSPECT NEW SAFEIO("","") DO ! Default
language is English ;
BEGIN .... using SAFEIO ......
closefiles;
END;
END program
By substituting the class SAFEI for SAFEIO (with the
language parameter only) the facilities numbered 1 to 6 will
still be present while the file handling facilities will
absent. The class SAFEI requires about 2/5 as much core as
SAFEIO.
By substituting SAFMIN still more SAFEIO facilities are
excluded. See SAFMIN.HLP. The size of SAFMIN is about 1/2
that of SAFEI.
The three classes SIMMIN, SIMEI and SIMEIO are identical in
all respects to SAFMIN, SAFEI and SAFEIO respectively but
are prefixed with SIMULATION.
**** SIMDBM Data Base Management System.
SIMBDM is a data base handling system based on the ideas in
the CODASYL DBTG proposal, but written entirely in SIMULA
for use by SIMULA programs. Facilities exist for defining
SCHEMAs (Data Base Structure Descriptions) and storing them
in the data base, and for accessing the SCHEMA from the
SIMULA program, for accessing data using the SCHEMA. Data
base fields of type Text or Array have indefinite length.
New fields can be added to existing records. Memory need
not be reserved for the largest instance of each record
type. Data base records are mapped onto CLASS instances in
core. A SIMULA program can access and use the SCHEMA, which
allows the writing of "data-independent" programs in SIMULA.
Restrictions: No built-in facilities exist for privacy
constraints or for solving multi-terminal access conflicts.
Written by Kalle M{kil{, Swedish National Defense Research
Institute.
DECsystem-10 SIMULA Language Handbook, part III Page 18
1. UTILITY PACKAGES
BASIC CONCEPTS
SIMDBM is a simple Data Base Management System (DBMS) based
on the CODASYL Task Group (DBTG) proposal. The DBMS system
described is written entirely in the SIMULA programming
language. It was developed to test how an interface between
SIMULA and a DBMS system can be arranged. The same
interface could then be used when interfacing SIMULA to a
larger DBMS system, not written in SIMULA.
Such an interface could use the same procedures to be called
from SIMULA and could map the data onto the same SIMULA-type
data structures in core. However, the actual procedures
would of course have to be rewritten.
Our experience is that our DBMS system itself is fully
usable for applications of moderate size. It is also,
because of its simple structure, useful as a tool in
teaching data base management techniques.
Two central concepts in the DBTG proposal are those of a
RECORD and a SET.
A RECORD is in some ways similar to a SIMULA CLASS. There
can be several types of RECORDs, each with a RECORD type
name. The RECORD is divided into FIELDs, which have a name
and a type, just like CLASS attributes in SIMULA.
A SET is a set of RECORDs. One RECORD is the OWNER of the
SET. The other RECORDs are called MEMBERs. The MEMBERs can
be of more than one RECORD type, and the number of MEMBERs
can vary.
SETs are often implemented by letting the OWNER refer to the
first MEMBER, that MEMBER to the next member etc. There
must also be a way of finding the OWNER from any of the
MEMBERs. This is either implemented by having a direct
reference from each MEMBER to the OWNER, or by letting the
last MEMBER in the chain refer back to the OWNER, so that
the OWNER can be found indirectly by following this chain
from any of the MEMBERs.
The SET concept can be used to create rather complex data
structures in the data base.
DECsystem-10 SIMULA Language Handbook, part III Page 19
1. UTILITY PACKAGES
IMPORTANT ASPECTS IN THE DEVELOPMENT OF THE SYSTEM
+++ The system should be easy to use for a person writing an
application program.
The manuals for a CODASYL-type DBMS system can be very
difficult to read, because of the many details. A simple
system can be a good introduction, and also be sufficient
for many applications. For more advanced applications, the
system is easy to extend, since it is written entirely in
SIMULA.
+++ Flexible data structures.
Data from the data base should be supplied in a form
suitable to the application program. A pre-processor can be
used to create SIMULA source program data structure
declarations, including procedures for reading and writing
data. These procedures will also convert between the
internal and external data format.
+++ Ways of extending the data base.
The user should be allowed to add new RECORD types and to
add more FIELDs to an existing RECORD type. This should not
require any change in old programs using the data base, and
old data in the data base should still be readable.
+++ The application program should have access to to a
description of the data base structure.
This makes it possible to write fully general purpose
programs, which do not depend on the actual structure of the
data base. These programs will thus work for any data base,
independent of the actual RECORD types, SETs and structures
in that data base.
An example would be a program which informs the user at a
conversational terminal about the structure of data, and
which allows him to read and write arbitrary data within the
structure of the data base.
Many commercial DBMS system do not have such a facility for
writing general-purpose programs in the high-level language.
DECsystem-10 SIMULA Language Handbook, part III Page 20
1. UTILITY PACKAGES
+++ The code of the DBMS system itself should be easy to read
and modify.
Since the system is written entirely in the high-level
language SIMULA, it is also easy to move from one computer
to another. The system is also rather small (about 1400
lines of SIMULA code), and we have carefully tried to keep
it simple, clean and well structured.
This makes it possible for an experienced SIMULA programmer
to get control over the system, to modify and extend it.
IMPORTANT ASPECTS WHICH WE HAVE NOT YET CONSIDERED.
+++ High efficiency in the use of CPU-time and core.
Certain effiency considerations have been made, but our main
goal has been to keep the program simple. The system can
probably be made very much faster by rewriting a few central
procedures in assembly language.
+++ Supporting several simultaneous users.
Every user program is a closed unit, which does not share
code with other people working against the data base.
Several users can simultaneously read the data base, but
only one at a time can write into it.
+++ Protection codes.
Codes to ensure security for parts of the data base has not
been introduced. This is however rather simple to add.
However, such codes are not necessary for many applications.
FILES ON THE DISTRIBUTION TAPE FOR SIMDBM:
External classes for use with SIMULA application programs
using SIMDBM: DBMTXT.SIM, DBM.SIM, DBMSET.SIM. (.ATR and
.REL files for these are part of SYS:LIBSIM).
Manuals: SIMDBM.RNO, SIMDBM.HLP.
General purpose program for terminal querys to data bases:
FETCH1.SIM, FETCH2.SIM, FETCH.SIM, FETCH.RNO, FETCH.HDA,
FETCH.SAV.
Loading of SIMDBM-data bases from a sequential file:
LOAD.SIM, LOAD.HLP.
Text editing of SIMULA direct access files from a terminal:
DECsystem-10 SIMULA Language Handbook, part III Page 21
1. UTILITY PACKAGES
DIRED.SIM, DIRED.HLP.
Entering a SCHEMA (Data Base Structure Specification) into a
data base: SPEC.SIM.
Preprocessor, producing SIMULA procedures for loading
records from a SIMDBM data base: PREP2.SIM.
Preprocessor, producing SIMULA class with internal
representation of records from a SIMDBM data base:
PREP1.SIM, PREP.SAV.
**** STORE is a simple text oriented data base handler providing
two main procedures PUTMESSAGE and GETMESSAGE. PUTMESSAGE
stores a message under a key in a direct access file, and
GETMESSAGE returns the message stored under a given key.
Both key and message can be text strings of arbitrary
length. STORE is distributed as the files STORE.SIM,
STORE.RNO, STORE.HLP and STOREU.SIM. STORE.RNO is STORE.HLP
in RUNOFF format. STOREU.SIM is an application example
which also uses the SAFEIO package.
Written by Jacob Palme, Swedish National Defence Research
Institute.
**** SELECT is a SIMULA class to facilitate the searching of TEXT
strings or files applying Boolean conditions like
"(SIMULA+ALGOL)&(DEC+DIGITAL)"
The Boolean condition is first translated into a formula
tree. This formula tree can then be applied to any number
of TEXTs, and TRUE will be returned for those TEXTs
containing words satisfying the Boolean condition.
Files: SELECT.SIM, SELECT.RNH and SELECT.HLP. In LIBSIM,
SELECT.REL and SELECT.ATR can be available.
Written by Jacob Palme, Swedish National Defence Research
Institute.
**** FIGURE is a basic graphic package for handling TEKTRONIX
graphic terminals in SIMULA. FIGURE is described in the
help file FIGURE.HLP and the programs are contained in the
files COSYS.SIM, COSYSF.SIM, FIGURE.HLP, FIGURE.SIM,
GETCH.ATR, GETCH.MAC, GETCH.REL, GRAPH.SIM, RUBOUT.ATR,
RUBOUT.MAC, RUBOUT.REL.
Written by Aake Blomberg, Swedish National Defence Research
Institute.
DECsystem-10 SIMULA Language Handbook, part III Page 22
1. UTILITY PACKAGES
**** VISTA is a package to get full control of an alphanumerical
display terminal. You can move the cursor freely around the
screen, and produce programs for e.g.:
> Moving pictures,
> Continuosly changing tables,
> Form-fill-in method of data entry with immediate validity
checking of each field,
> Table-fill-in method of data entry with immediate validity
checking of each field.
VISTA will only work on display terminals of type INFOTON
VISTA, but is prepared for modification to other display
terminals.
Files: VISTA.SIM, FORM.SIM, CAT.SIM, SHIP.SIM, FORMT.SIM,
VISTA.RNM, VISTA.RNH.
Written by Jacob Palme, Swedish National Defence Research
Institute.
**** DAHELP
The DAHELP class may be used in order to save core in
application programs when the HELP texts are very long
and/or many.
If you prepare a number of sequential files with names equal
to the respective keywords, the MAKHLP program may be used
in order to create a DAHELP direct access file. This file
could then be used by the DAHELP class in order to display
any of the included (sub)files on the TTY (Sysout i.e.). It
is also possible to make DAHELP list all entries (keywords)
in the DAHELP file.
Written by Mats Ohlin, Swedish National Defense Research
Institute. Files: DAHELP.SIM, DAHELP.HLP, and in LIBSIM
DAHELP.ATR, DAHELP.REL.
DECsystem-10 SIMULA Language Handbook, part III Page 23
1. UTILITY PACKAGES
**** SQHELP is a program to simplify the provision of a help
facility in a conversational program, where different parts
of the help file may be printed via different help requests
in the program.
SQHELP is based on a sequential search of the help file, and
display of all pages containing a certain word. Compared to
DAHELP, this has the following advantages and disadvantages:
> The help file can be sequential file, readable also with the
monitor HELP command and requiring less core than direct
access files.
> The user can supply key words to guide the help file search.
> Much slower than DAHELP, not suitable for very large help
files.
> The search is governed by words contained in the help file
text, not by the title of the help file segments.
Files: SQHELP.SIM, SQHELP.RNH and SQHELP.HLP. LIBSIM can
contain SQHELP.ATR and SQHELP.REL.
Written by Jacob Palme and Mats Ohlin, Swedish National
Defence Research Institute.
**** DECOM is a package to simplify the writing of SIMULA
programs which accept input in the conventional DEC-10
format:
OUTFIL.EXT/SWITCH1/SWITCH2...=INFIL.EXT/SWITCH3/SWITCH4/SWITC
H5...
DECOM is a subclass of SAFMIN (See SAFEIO).
Files: DECOM.SIM and DECOM.HLP. DECOM.ATR and DECOM.REL
can be available in LIBSIM.
Written by Jacob Palme and Mats Ohlin, Swedish National
Defence Research Institute.
DECsystem-10 SIMULA Language Handbook, part III Page 24
1. UTILITY PACKAGES
**** SIMDEM.PAC
The file SIMDEM.PAC contains a couple of simple SIMULA
programs which can be used to demonstrate the ideas of the
SIMULA programming language.
The programs in the package are:
QASETE, which is a very simple question-answering system
accepting statements like "BOOK IS DOCUMENT. DOCUMENT IS
OBJECT." and being able to answer questions like "IS BOOK
OBJECT?".
STAT1E, which is a very simple simulation program of the
transport operation between a harbour a store and a factory.
The simulation program lacks all tracing and result output.
STAT2E is the same simulation program as in STAT1E, but with
tracing and result output added without any cluttering up of
the proper simulation program. The intention is to
illustrate the power of the SIMULA language for this kind of
structured programming.
DECsystem-10 SIMULA Language Handbook, part III Page 25
2. SIMULA SOURCE PROGRAM CONVERSION PROGRAMS
2. SIMULA SOURCE PROGRAM CONVERSION PROGRAMS
---------------------------------------------
**** SIMED is a program to convert SIMULA source programs to a
more readable format. The block structure is indicated by
indentation and reserved words are (optionally) capitalized
to distinguish them from other identifiers. SIMED is
described further in the DECsystem-10 SIMULA Language
Handbook Part II Appendix L. SIMED is distributed as four
files, SIMED.SIM, SIMED.DAT, SIMED.HLP and SIMED.SAV.
Written by Mats Ohlin, Swedish National Defence Research
Institute.
**** SIMSTR [NOT READY]
Documents a SIMULA program by extracting only structural
lines from the program.
**** IBMSIM is a program to convert SIMULA source programs from
IBM 360/370 to DECsystem-10. The program is described in
Appendix M.1 of the DECsystem-10 SIMULA Language Handbook
Part II. IBMSIM is distributed as three files, IBMSIM.SIM,
IBMSIM.HLP and IBMSIM.SAV.
Written by Mats Ohlin, Swedish National Defence Research
Institute.
**** SIMIBM is a program to convert SIMULA source programs from
DECsystem-10 to IBM 360/370. The program is described in
Appendix M.2 of the DECsystem-10 SIMULA Language Handbook
Part II. SIMIBM is distributed as three files, SIMIBM.SIM,
SIMIBM.HLP and SIMIBM.SAV.
Written by Mats Ohlin, Swedish National Defence Research
Institute.
**** CDCSIM is a program to convert SIMULA source programs from
CDC to DECsystem-10. The program is described in Appendix
M.3 of the DECsystem-10 SIMULA Language Handbook Part II.
CDCSIM is distributed as two files, CDCSIM.SIM and
CDCSIM.SAV.
Originally produced at the Norwegian Computing Center,
modified by Lars Enderin and Jacob Palme at the Swedish
National Defence Research Institute.
**** SIMEXP is a program to merge a SIMULA source program
containing separately compiled segments into one single
segment. This is necessary when using the program
measurement system FQC and sometimes necessary when moving
SIMULA programs from the DECsystem-10 to other computers.
SIMEXP is described in SIMEXP.HLP and distributed as
SIMEXP.SIM and SIMEXP.SAV.
DECsystem-10 SIMULA Language Handbook, part III Page 26
2. SIMULA SOURCE PROGRAM CONVERSION PROGRAMS
Written by Mats Ohlin, Swedish National Defence Research
Institute.
**** FQC is a program to measure the frequency with which the
statements in a SIMULA program are executed. FQC is
described in Appendix J in the DECsystem-10 SIMULA Language
Handbook Part II. FQC is distributed as FQCRED.SIM,
FQCRED.SAV, FQCLST.SIM, FQCLST.SAV, FQC.HLP, FQC1.MIC,
FQC2.MIC.
Written by Stefan Arnborg, Swedish National Defence Research
Institute.
DECsystem-10 SIMULA Language Handbook, part III Page 27
3. DIRECTFILE HANDLING PROGRAMS
3. DIRECTFILE HANDLING PROGRAMS
--------------------------------
**** DIRED program
A general editor for DIRECTFILEs.
Files: DIRED.SIM, DIRED.SAV, DIRED.HLP.
Written by Kalle M{kil{, Swedish National Defense Research
Institute.
**** MAKEDF program
Converts a sequential file into a DIRECTFILE.
Files on the distribution tape: MAKEDF.SIM, MAKEDF.SAV,
MAKEDF.HLP.
Written by Kalle M{kil{, Swedish National Defense Research
Institute.
**** FETCH program
FETCH is part of the SIMDBM package. FETCH allows you to
access the data base directly from a terminal, without
running any programs. Changes to the SCHEMA must however be
made with the program SPEC. See further the SIMDBM
documentation.
Written by: Kalle M{kil{, Swedish National Defense Research
Institute.
**** MAKHLP program
The MAKHLP program modifies or creates a DAHELP Direct
Access Help file by appending named sequential file
references.
MAKHLP can not delete any parts of the Direct Access file.
For such purposes - reconstruct the file from scratch or use
the DIRED program to patch up the file according to DAHELP
format (imagesize:73). See DAHELP.HLP for more information.
IMPORTANT - never change the number of symbols per line
equal to 73 + <CR> + <LF> in a Direct Access DAHELP File.
(Since (imagesize+2) mod 5 = 0 TECO may be used, but
CAREFULLY!!)
DECsystem-10 SIMULA Language Handbook, part III Page 28
3. DIRECTFILE HANDLING PROGRAMS
Files on the distribution tape: MAKHLP.SAV, MAKHLP.SIM,
MAKHLP.HLP.
Note! The input file(s) may not contain the character '}'
(tilde - ASCII 176 octal) in column 1 (it will disappear).
Requested information is -
1. Name of DAHELP file to be created. Default extension is
.HLP.
2. Name(s) of sequential input files to be appended.
(Default extension is .HLP)
3. For each input file - enter DAHELP file ENTRY key word.
Up to 64 characters (translated to upper case) will be
included. If no answer (i.e. empty line), the input
file name will be used.
End dialogue with EXIT (or ↑Z).
BOOLEAN PROCEDURE connect(filespec); VALUE filespec; TEXT
filespec; BEGIN INSPECT findinfile(filespec) DO BEGIN
open(blanks(80)); INSPECT findoutfile(filespec) DO BEGIN
open(blanks(80)); connect:= TRUE; outtext( "THIS TERMINAL
IS NOW CONNECTED!"); outimage; ACTIVATE NEW terminal(THIS
infile, THIS outfile); END OTHERWISE close; END; END;
DECsystem-10 SIMULA Language Handbook, part III Page 29
4. PROCEDURES NOT WRITEABLE IN SIMULA
4. PROCEDURES NOT WRITEABLE IN SIMULA
--------------------------------------
NOTE: Some of these routines are not yet written. See the
list in chapter 0.2, which indicates which routines are
ready.
The source code for these routines can usually be found in
the large file LIBSIM.PAC. Unpack the individual files with
the program FILPAC.SAV. FILPAC.SAV places the unpacked
files on DSKD. If you want the files on another file
structure, say DSKB, do .ASSIGN DSKB DSKD before running
FILPAC.
4.1 TIME AND DATE
**** TEXT PROCEDURE TODAY
Parameters: none
Result: Reference to a text object of length 10 with contents:
yyyy-mm-nn
where yyyy is year, mm is month(in digits 01-12), nn is day
(in digits 01-31). This is the internationally standardized
format for dates.
**** TEXT PROCEDURE DAYTIME
Parameters: none
Result: Reference to a new text object of length 8 with
contents:
hh:mm:ss
where hh is hours
mm is minutes
ss is seconds.
at the time of the call.
This is the internationally standardized format for writing
time-of-day.
**** PROCEDURE TIMELIMIT
Parameters: A time limit for the job measured in seconds of CPU
time.
Result: The execution will be interrupted when the allotted time
is up. If the argument is non-positive, the effect will be
as if TIMELIMIT was never called.
DECsystem-10 SIMULA Language Handbook, part III Page 30
4.1 TIME AND DATE
**** [LONG] REAL PROCEDURE CPTIME
Parameters: none
Result: Total CPU time spent since the beginning of the SIMULA
program execution, expressed in seconds. The resolution is
implementation dependent. The procedure should only be LONG
REAL if this provides any extra significant information.
**** [LONG] REAL PROCEDURE CLOCKTIME
Parameters: none
Result: Time of day in seconds, i.e. the absolute difference
between the results of two successive calls is the time
which elapsed between the calls (except when passing
midnight). Resolution is implementation dependent. LONG
REAL should only be used if this gives extra significance.
4.2 REAL-TIME FOR MULTI-TERMINAL SIMULTANEOUS I/O.
[PRE-RELEASE VERSION]
The goal of this is to allow one program to talk
simultaneously to several conversational terminals and other
on-going processes (jobs) in the computer. A break in one
such dialouge should not inhibit the conversation with the
other terminals and processes.
Chapter 4.2.1 below describes three simple assembly
procedures which you can use if you want to write your own
scheduling of the parallel processes for handling the
external devices.
Chapter 4.2.2 to 4.2.5 below describe a simple scheduler for
realtime applications written in SIMULA. The scheduler
allows you to use SIMULA processes, one for each external
device.
This is based on FOA P Report C 8394 (June 1974): "Making
SIMULA into a Programming Language for Real Time" by Jacob
Palme. (Published in Management Informatics, Vol. 4, No. 4,
August 1975, pp. 129-138.)
DECsystem-10 SIMULA Language Handbook, part III Page 31
4.2 REAL-TIME FOR MULTI-TERMINAL SIMULTANEOUS I/O.
4.2.1 BASIC ASSEMBLY PROCEDURES FOR REAL TIME
**** BOOLEAN PROCEDURE INPUTCHECK(inputfile); REF (infile)
inputfile;
The parameter infile is connected to an external device or
another job process. INPUTCHECK will return TRUE if an
INIMAGE can be made on the INFILE without delay, that is if
data for the INIMAGE is already available. If the external
device has not yet replied, then INPUTCHECK will return
FALSE. INPUTCHECK will also return FALSE if the parameter
is NONE, refers to a closed file or refers to a file where
ENDFILE is TRUE.
**** PROCEDURE SLEEP. This procedure takes one parameter of type
REAL and will stop the execution for a real time interval of
at least this duration (seconds). Resolution is 0.001 on a
DECsystem-10.
**** INTEGER PROCEDURE INPUTWAIT(filearray,maxtime);
REF (infile) ARRAY filearray; REAL maxtime;
This procedure stops the execution of the ongoing SIMULA
program until INPUTCHECK would be TRUE for at least one of
the parameter files, or until MAXTIME seconds have elapsed.
MAXTIME = 0 indicates no time limit on the wait. Some of
the array elements may be NONE. Whenever INPUTCHECK would
be TRUE for one of these files, execution of the SIMULA
program continues. If INPUTCHECK is already TRUE for one of
the files when INPUTWAIT is called, then INPUTWAIT will
return immediately to the calling program. The procedure
returns an integer which is the index of a file in the
parameter array from which input has been received, not
necessarily the first one if input has been received from
more than one of the input files. INPUTWAIT disregards
those array elements which are NONE or which refer to closed
files, or files with ENDFILE = TRUE. If all the array
elements are disregarded in this way, then inputwait does
not stop execution but returns an integer which is 1 less
than the lower bound of the parameter array. If the wait
was interrupted becuse of the time limit maxtime, then an
integer which is 2 less than the lower bound of the
parameter array is returned.
DECsystem-10 SIMULA Language Handbook, part III Page 32
4.2 REAL-TIME FOR MULTI-TERMINAL SIMULTANEOUS I/O.
4.2.2 REALTIME - A SCHEDULER FOR TERMINAL PROCESSES
===================================================
REALTIME is a separately compiled CLASS written in SIMULA as
a subclass to SIMULATION. REALTIME is based on the idea
that you have one SIMULA process connected to each
conversational terminal. The processes can then execute in
parallel, and the SIMULATION scheduler is used to distribute
the execution between the terminals. The CLASS REALTIME is
not only useful for simulation programs, it can be used for
other real time applications too.
The simplest kind of real time application is the execution
of a conversational program running under a time-sharing
system with one external user talking to the program through
a terminal such as a display unit or a typewriter terminal.
This simple kind of conversation can already easily be
programmed in SIMULA. The time-sharing operating system
will handle all the real time problems for the SIMULA
program.
But as soon as we want more than one real process to
communicate simultaneously with the SIMULA program, then we
need more advanced real time capabilities.
Examples:
- During a simulation, we may want to program part of the
simulation in SIMULA but let real components, for example
real human participants, play certain parts in the
simulation.
- We want to let more more than one user at his terminal
simultaneously access a data base, both fetching and storing
information in it. One master program has to coordinate the
data base accesses so that two users do not simultaneously
try to update the same record. We might want to write this
program in SIMULA.
DECsystem-10 SIMULA Language Handbook, part III Page 33
4.2 REAL-TIME FOR MULTI-TERMINAL SIMULTANEOUS I/O.
4.2.3 Procedures WAITFORINPUT, INPUTCHECK and HOLD(0).
The execution of a SIMULA process is only interrupted where
explicit statements like "HOLD" or "PASSIVATE" cause control
to transfer from the process to the scheduler. A common
error when programming real time programs is that one
parallel process uses partly updated data, produced by
another parallel process. For small in-core updates, a
programmer in SIMULA can avoid this error by only putting
statements like "HOLD" and "PASSIVATE" at places in the
source program where data updates are complete.
For more complex updates, a special process can be written
to access the critical data, and other processes requesting
updates can be queued to the special process. When a SIMULA
process executes a statement like "HOLD" or "PASSIVATE",
then control goes to the SIMULA scheduler, which then
transfers control to another process.
"HOLD(A)" stops execution of the current process but asks
the SIMULA scheduler to restart it after A time units. If A
is zero, then the current process is stopped and placed at
the end of a queue of currently active processes. If a
number of processes successively make "HOLD(0.0)" they will
thus get access to the CPU in a round robin fashion.
A SIMULA programmer can thus ensure fast response to
external interrupts by not doing too much computations
between successive "HOLDS".
"PASSIVATE" stops the current process indefinitely, it must
be activated again from some other process.
Processes waiting for external interrupts are put into a
special queue with the procedure call "WAITFORINPUT". The
"SIMULATION CLASS REALTIME" contains a special version of
"HOLD" and an alternative version of "PASSIVATE" called
"TERMINAL←PASSIVATE" and these procedures first scan this
special queue to see if data has arrived from the input
device associated with the terminal processes.
If a process is found for which data has arrived on the
associated input device, then the SIMULA scheduler activates
this process immediately.
The event created by the first external interrupt found is
thus placed in front of other currently active processes in
the sequencing set. This, however, is not done at the time
of the interrupt, the placing is done at the time of the
next activation of the scheduler after the interrupt.
Inside a terminalprocess, a call "WAITFORINPUT" will thus
tell the system to make this process passive, but to
reactivate it as soon as new data has arrived on the input
device associated with the process.
A new BOOLEAN standard procedure INPUTCHECK is also
introduced. INPUTCHECK is TRUE if and only if data is
available (i.e. has arrived from the terminal device) for
reading with INIMAGE.
DECsystem-10 SIMULA Language Handbook, part III Page 34
4.2 REAL-TIME FOR MULTI-TERMINAL SIMULTANEOUS I/O.
4.2.4 Procedures CLOCKTIME, SYNCHRONIZE and DESYNCHRONIZE.
For real time applications, we may also want to synchronize
simulated time with real time. For this there are three new
standard procedures:
REAL PROCEDURE CLOCKTIME; COMMENT gives time in seconds
since the beginning of the current day;
PROCEDURE synchronize(timeunit); REAL timeunit; COMMENT
this procedure starts synchronization of real and simulated
time;
PROCEDURE desynchronize; COMMENT and this stops
synchronization;
Of course perfect synchronization of real and simulated time
is not possible since the speed of the computer itself is
not infinite. The package tries to synchronize, and never
allows simulated time to become more than a fraction of a
second larger than real time.
The package requires more CPU time when synchronized than
when desynchronized.
If the scheduler finds that the next process to be scheduled
has a too large simulated time, then the SIMULA scheduler
lets the SIMULA program go to sleep for the necessary time
interval. Any interrupts caused by input will however start
the SIMULA program again.
The parameter "timeunit" to the procedure "synchronize" is
there since the time unit may not be the same in the
simulation and in the real world. "timeunit" is the size of
the simulation time unit in seconds. Thus, if simulated
time is measured in seconds, "timeunit" should be 1.0, if
simulated time is measured in hours, "timeunit" should be
60*60.
DECsystem-10 SIMULA Language Handbook, part III Page 35
4.2 REAL-TIME FOR MULTI-TERMINAL SIMULTANEOUS I/O.
4.2.5 Structure of the class REALTIME
OPTIONS(/E);
EXTERNAL BOOLEAN PROCEDURE inputcheck;
EXTERNAL PROCEDURE sleep, abort;
EXTERNAL INTEGER PROCEDURE inputwait;
EXTERNAL REAL PROCEDURE clocktime;
simulation CLASS realtime;
NOT HIDDEN PROTECTED synchronize, desynchronize,
terminalpassivate,
hold, terminalprocess;
NOT HIDDEN process, current, time, passivate, wait,
main, linkage, link, head;
BEGIN
PROCEDURE synchronize(timeunit); REAL timeunit;
COMMENT this procedure starts synchronization of real and
simulated time;
BEGIN ... END;
PROCEDURE desynchronize;
COMMENT This procedure ends synchronization of real and
simulated time;
BEGIN ... END;
PROCEDURE terminalpassivate;
COMMENT special version of passivate for a
terminalprocess;
BEGIN ... END;
PROCEDURE wait(q); REF (head) q;
COMMENT special version of wait for a terminalprocess;
BEGIN ... END;
PROCEDURE hold(delaytime); REAL delaytime;
COMMENT special version of hold for terminalprocesses.
hold(0.0) gives round robin process scheduling;
BEGIN ... END;
process CLASS terminalprocess(fromterminal);
REF (infile) fromterminal;
NOT HIDDEN PROTECTED fromterminal, waitforinput;
NOT HIDDEN evtime, nextev, into;
BEGIN
PROCEDURE waitforinput;
COMMENT this process waits in the inputarray
inimage is possible to make;
BEGIN ... END;
END of terminalprocess;
END of class realtime;
DECsystem-10 SIMULA Language Handbook, part III Page 36
4.2 REAL-TIME FOR MULTI-TERMINAL SIMULTANEOUS I/O.
4.2.6 Application examples.
In this section you can see how the new concepts can be
used. Some examples will be given of real time programs
written in SIMULA using the new concepts.
The programs are not always complete. Three dots indicate
places where something has been left out.
4.2.6.1.1 Simultaneous, uninterfered dialogue between
the computer and several real terminals.
One master terminal reads file specifications for the other
terminals and starts up one copy of the SIMULA CLASS
"terminal" for each of the other terminals. Each of these
"terminalprocesses" will open the connection to its real
terminal, and then go into a loop of (a) waiting for input
and (b) producing answers.
Each of these terminal loops will go on independently of the
other, and the SIMULA scheduler will distribute control
between the "terminalprocesses".
terminalprocess CLASS terminal(toterminal);
REF (outfile) toterminal;
BEGIN
INSPECT fromterminal DO
INSPECT toterminal DO
BEGIN
PROCEDURE open←terminal←connections; ...
PROCEDURE read←the←input←and←produce←an←answer; ...
WHILE TRUE DO
BEGIN
waitforinput;
read←the←input←and←produce←an←answer;
END;
END;
END;
ACTIVATE NEW terminal(sysin,sysout);
ACTIVATE NEW terminal(NEW infile("TTY2:"),
NEW outfile("TTY2:"));
ACTIVATE NEW terminal.....
....
passivate;
DECsystem-10 SIMULA Language Handbook, part III Page 37
4.2 REAL-TIME FOR MULTI-TERMINAL SIMULTANEOUS I/O.
4.2.6.1.2 A complete program using the CLASS REALTIME.
Here follows a complete, small program using the CLASS
REALTIME.
The program returns at each terminal the input
received at that terminal. If the input at a terminal
is a legal TTY device specification, that terminal
is connected to the program.
BEGIN
EXTERNAL BOOLEAN PROCEDURE inputcheck;
EXTERNAL PROCEDURE sleep, abort;
EXTERNAL INTEGER PROCEDURE inputwait;
EXTERNAL REAL PROCEDURE clocktime;
EXTERNAL CLASS realtime;
EXTERNAL REF (infile) PROCEDURE findinfile;
EXTERNAL REF (outfile) PROCEDURE findoutfile;
realtime BEGIN
terminalprocess CLASS terminal(toterminal);
REF (outfile) toterminal;
BEGIN
TEXT stripimage;
INSPECT fromterminal DO INSPECT toterminal DO
WHILE fromterminal.image.sub(1,2) NE "/*" DO
BEGIN
waitforinput; inimage;
stripimage:- fromterminal.image.strip;
IF stripimage =/= NOTEXT THEN
BEGIN
IF stripimage.sub(stripimage.length,1)
= ":" THEN
BEGIN COMMENT Connect another terminal;
IF connect(stripimage) THEN
outtext("NEW LINE OPEN. ") ELSE
outtext("NOT ABLE TO OPEN THAT LINE. ");
END;
END;
outtext("I received: '");
outtext(stripimage); outtext("'");
outimage;
END;
toterminal.close; fromterminal.close;
END;
DECsystem-10 SIMULA Language Handbook, part III Page 38
4.2 REAL-TIME FOR MULTI-TERMINAL SIMULTANEOUS I/O.
BOOLEAN PROCEDURE connect(filespec);
VALUE filespec; TEXT filespec;
BEGIN
INSPECT findinfile(filespec) DO
BEGIN
open(blanks(80));
INSPECT findoutfile(filespec) DO
BEGIN
open(blanks(80));
connect:= TRUE;
outtext(
"THIS TERMINAL IS NOW CONNECTED!");
outimage;
ACTIVATE NEW terminal
(THIS infile, THIS outfile);
END
OTHERWISE close;
END;
END;
ACTIVATE NEW terminal(sysin, sysout);
passivate;
END of realtime prefixed block;
END of the whole program;
4.2.6.2 Data base system, several terminals
use the same data base.
This is a very simple example of a data base system with
several conversational terminals which independently put
requests (questions or updates) to a data base. The actual
data base accesses must be done for only one request at a
time to avoid errors when one terminal tries to read what
another terminal is updating.
The SIMULA program contains one process for each terminal
and one process for the data base.
The terminal processes wait for input from their respective
terminals. When a data base request has been received, the
terminal process is put into a queue of data base requests.
The data base process takes one terminal process at a time
from this queue and processes the data base request.
Thereafter, the data base process ACTIVATEs the terminal
process again. When ACTIVATEd, this terminal process writes
the answer to its terminal and waits for new requests from
it.
DECsystem-10 SIMULA Language Handbook, part III Page 39
4.2 REAL-TIME FOR MULTI-TERMINAL SIMULTANEOUS I/O.
realtime BEGIN
REF (head) request←queue;
REF (data←base) the←data←base;
terminalprocess CLASS terminal(toterminal);
REF (outfile) toterminal;
BEGIN
INSPECT fromterminal DO
INSPECT toterminal DO
BEGIN
PROCEDURE open←terminal←line; ...
PROCEDURE read←and←prepare←data←base←request; ...
PROCEDURE write←the←answer←to←the←request; ...
WHILE TRUE DO
BEGIN
waitforinput;
read←and←prepare←data←base←request;
ACTIVATE the←data←base DELAY 0;
wait(request←queue);
write←the←answer←to←the←request;
END;
END;
END;
process CLASS data←base;
BEGIN
INSPECT NEW
directfile(data←base←file←specifications) DO
BEGIN
PROCEDURE open←data←base←file; ...
PROCEDURE put←the←request←to←the←data←base; ...
open←data←base←file;
WHILE TRUE DO
INSPECT request←queue.first WHEN terminal DO
BEGIN
out; COMMENT to remove the terminal from the
request queue;
put←the←request←to←the←data←base;
ACTIVATE THIS terminal;
END OTHERWISE passivate;
END;
END;
4.2.6.3 Limited response time for the terminal operator.
This is a very simple example of a program which is
coordinated with the time in the real world. A question is
given to a terminal operator and the program waits for an
answer. The program should take different action depending
on whether the answer is received within 60 seconds or not.
To do this, the new standard procedure SYNCHRONIZE is used
to synchronize real time with the simulated time in SIMULA.
DECsystem-10 SIMULA Language Handbook, part III Page 40
4.2 REAL-TIME FOR MULTI-TERMINAL SIMULTANEOUS I/O.
terminalprocess CLASS terminal(toterminal);
REF (outfile) toterminal;
BEGIN
INSPECT fromterminal DO
INSPECT toterminal DO
BEGIN
REAL questiontime;
PROCEDURE write←question←to←the←terminal; ...
PROCEDURE process←fast←answer; ...
PROCEDURE process←slow←answer; ...
synchronize(1.0);
write←question←to←the←terminal;
questiontime:= time;
waitforinput;
IF time - questiontime < 60.0 THEN
process←fast←answer ELSE
process←slow←answer;
END;
END;
4.2.6.4 A conversational time-sharing system.
The conversational time-sharing system in this example could
be an interpreter for a language like APL or FOCAL or AID.
Highest priority is given to those input commands which are
to be performed directly. Lower priority is given to input
commands requesting the execution of a stored program. When
several stored programs are in execution at the same time,
CPU power is distributed between them in a round robin
fashion letting each program perform one statement in the
stored program before continuing to the next program.
DECsystem-10 SIMULA Language Handbook, part III Page 41
4.2 REAL-TIME FOR MULTI-TERMINAL SIMULTANEOUS I/O.
terminalprocess CLASS terminal(toterminal);
REF (outfile) toterminal;
BEGIN
INSPECT fromterminal DO
INSPECT toterminal DO
BEGIN
PROCEDURE open←terminal←connections; ...
PROCEDURE read←the←input←and←produce←an←answer;
BEGIN
BOOLEAN more←statements, execute←command;
PROCEDURE read←and←interpret←an←input←line; ...
PROCEDURE
execute←the←next←stored←program←statement; ...
PROCEDURE perform←the←command←from←the←input←line;
...
read←and←interpret←an←input←line;
IF NOT execute←command THEN
perform←the←command←from←the←input←line ELSE
WHILE more←statements DO
BEGIN
HOLD(0); COMMENT to transfer control to another
process;
execute←the←next←stored←program←statement;
END;
END;
WHILE TRUE DO
BEGIN
waitforinput;
read←the←input←and←produce←an←answer;
END;
END;
END;
4.2.6.5 Coordinated control of simultaneous real processes.
When a real time computer program communicates with several
simultaneous processes in the real world, the computer
program may want to control itself or the real-world
processes depending on the results in the various processes.
Example 1: A simulation program may want to continue the
simulation when all the terminals have replied to certain
questions.
Example 2: A process control program may monitor several
real-world processes, and initiate other real-world actions
when previous processes are ready.
This is similar to PERT-networks in planning, where certain
actions must wait for other actions to finish.
To illustrate this, a simple example assumes a robot with
three arms. A process "put nail in board" is initiated.
This process initiates three simultaneous processes, the
first arm gets a hammer, the second arm gets a nail, and the
third arm gets a board. When all these three processes are
DECsystem-10 SIMULA Language Handbook, part III Page 42
4.2 REAL-TIME FOR MULTI-TERMINAL SIMULTANEOUS I/O.
finished, the hammer is used to push the nail into the
board.
In other languages, special constructs like "fork" and
"join" are used to create parallel processes and then
continue when all the processes are ready. But the same
thing is very simple to program in SIMULA, and in SIMULA we
do not have to wait until a process is fully finished, we
can also easily start a later process when still running
processes have reached certain states.
terminalprocess CLASS arm(toterminal);
REF (outfile) toterminal;
BEGIN
INSPECT fromterminal DO
INSPECT toterminal DO
BEGIN
TEXT order; BOOLEAN ready; REF (process) master;
PROCEDURE perform←order; ...
WHILE TRUE DO
BEGIN
terminal←passivate;
ready:= FALSE; perform←order; ready:= TRUE;
ACTIVATE master DELAY 0;
END;
END;
END;
process CLASS put←nail←in←board(arm1, arm2, arm3);
REF (arm) arm1, arm2, arm3;
BEGIN
arm1.order:- copy("find hammer"); arm1.master:- current;
arm2.order:- copy("find nail"); arm2.master:- current;
arm3.order:- copy("find board"); arm2.master:- current;
ACTIVATE arm1 DELAY 0;
ACTIVATE arm2 DELAY 0;
ACTIVATE arm3 DELAY 0;
terminal←passivate;
WHILE NOT (arm1.ready AND arm2.ready AND arm3.ready)
DO terminal←passivate;
arm1.order:- copy("swing hammer");
ACTIVATE arm1 DELAY 0;
...
END;
DECsystem-10 SIMULA Language Handbook, part III Page 43
4.2 REAL-TIME FOR MULTI-TERMINAL SIMULTANEOUS I/O.
4.2.6.6 Simultaneous dialogue and execution.
On many occations, you may want a program to execute and
talk to the user at the same time. You may for example want
to allow the user to ask the computer how far the execution
has reached. This is especially useful for time-consuming
executions, where the user may get impatient and may want to
know if the delay is caused by machine error, erroneous data
to the program, by a heavy load on the machine or just by a
time-consuming execution in general.
One can then write a program with two processes, one process
for talking to the user and another process for the
time-consuming execution.
terminalprocess CLASS userdialogue(toterminal);
REF (outfile) toterminal;
BEGIN
INSPECT fromterminal DO
INSPECT toterminal DO
BEGIN
ACTIVATE NEW cpuactivity DELAY 0;
WHILE TRUE DO
BEGIN
outline("CPU activity has begun. If you want to");
outline("know what is happening, then write");
outline("""?"" on your terminal");
waitforinput; inimage;
tell←the←user←what←is←happening;
END;
END;
END;
DECsystem-10 SIMULA Language Handbook, part III Page 44
4.3 INPUT/OUTPUT
4.3 INPUT/OUTPUT
4.3.1 ASCII-FORMATTED I/O
**** INTEGER PROCEDURE LINECOUNT
Parameters: One parameter. The parameter should be a reference
to an open printfile object.
Result: Value of LINESPERPAGE attribute of the printfile.
**** TEXT PROCEDURE FILENAME
Parameter: One parameter, which is a simple valid reference to
an object of an I/O class.
Result: Reference to a text object whose value is equal to the
NAME parameter of the FILE object. The resulting text value
may or may not be stripped of blanks before return.
**** CHARACTER PROCEDURE INSINGLECHAR
Parameters: One reference to an infile object using a terminal.
Result: Returns next input character from the terminal (after
last INIMAGE) without waiting for break character.
Succeeding INIMAGE will begin reading after the character(s)
which has been input with INSINGLECHAR.
Restriction: With release 3 of DECsystem-10 SIMULA,
INSINGLECHAR only works on the controlling terminal.
**** CHARACTER PROCEDURE GETCH
GETCH is similar to INSINGLECHAR (See above) but has no
parameter and always takes input from the conversational
terminal controlling the current job.
**** BOOLEAN PROCEDURE NUMBERED
The BOOLEAN PROCEDURE numbered should always be called
immediately after inimage. It will return TRUE if the last
input line was numbered. The internal flag will be reset by
numbered and may be changed by each inimage, even on other
files. For output of line-numbered files, see the
DECsystem-10 SIMULA Language Handbook part II about the file
creation switch /NUMBERED.
DECsystem-10 SIMULA Language Handbook, part III Page 45
4.3.1 ASCII-FORMATTED I/O
**** PROCEDURE ECHO(fileref,mode); REF(Infile)fileref; INTEGER
mode;
COMMENT Provided fileref refers to a TTY file, different
values of mode have the following effects:
mode=0 resets the mode to normal.
mode=1 sets special editor mode.
mode=2 suppresses echoing on the terminal completely.
mode=4 causes all characters to echo exactly as typed.
Combinations are possible where meaningful, i e 5=4+1. No
effect on other files;
**** TEXT PROCEDURE TMPNAM
TMPNAM takes one parameter, a text constant, variable or
expression whose first three characters (or fewer than 3 if
the length of the text is less) are used when forming a
temporary file name which is the value of TMPNAM. The name
has the form "jjjppp.TMP", where jjj is the current job
number in decimal notation, and ppp are the first three or
fewer characters of the parameter to TMPNAM.
File names of this form are used for command files to
standard CUSP's, such as SIMULA, PIP, LINK-10 and should
also be useful for internal scratch files in a SIMULA
program. See the RUN procedure for examples.
**** PROCEDURE READ
Parameters: Any parameters of type integer, (long) real or
character. A reference type parameter, if used, must be a
reference to an object of class infile or directfile. A
parameter may be an array identifier of suitable type.
Notes: New values for the actual parameters are obtained one by
one from the current input file (initially SYSIN). If a
parameter is an array identifier, new values are read and
assigned for all elements of the array. A parameter which
is a reference to an open infile or directfile causes all
successive read operations (in the parameter list) to be
applied to this file.
DECsystem-10 SIMULA Language Handbook, part III Page 46
4.3.1 ASCII-FORMATTED I/O
**** PROCEDURE WRITE
Parameters: Any parameters of type integer, (long) real,
character or text. Constants and arrays are also allowed.
A reference type parameter, if used, must be a simple
reference to an object of class outfile, printfile or
directfile.
Notes: Values of actual parameters are output one by one on the
current output file (initially SYSOUT). The output formats
for the respective values are
integer i outint(i,n) where n is the number of digits
printed for the largest possible integer on
this machine plus 1
real x print x in flexibel format according to:
if x = 0 then outfix(x,0,w) else
if abs(x) >= 10↑d then outreal(x,d,w) else
if abs(x) >= 10↑(-e) then
outfix(x,d-ilog(x)+(if abs(x) >= 1 then 0
else -1),w)
else outreal(x,d,w);
where d is number of significant digits, e
is number of positions required for the
exponent part and w := e + d + 2 (sign and
dot positions).
long real z same as for real but for long real
significance
character c outchar(c)
text t outtext(t)
If the actual parameter is an array identifier, the values
of all its elements are output. A parameter which is a
reference to an open printfile, outfile or directfile,
causes all successive output operations to be applied to
this file. SYSOUT may not be used explicitly as a parameter
to WRITE. Each call on WRITE ends with a call on OUTIMAGE
which also is called implicitly if the image is filled
before all parameters are processed. The final OUTIMAGE
concerns every file mentioned; thus OUTIMAGE (for the
previous file) is called when a new file reference is given
as well as at the end of the parameter list.
DECsystem-10 SIMULA Language Handbook, part III Page 47
4.3.2 UNFORMATTED (BINARY) I/O.
4.3.2 UNFORMATTED (BINARY) I/O.
*********************** WARNING **************************
* Use of the procedures described in this section may make *
* your programs difficult to move to another SIMULA system.*
************************************************************
Unformatted I/O is a tricky problem because we have many
diverse requirements to put together, if possible, in one
construct.
> Very fast and efficient input and output of much data.
> Simple input and output procedures, taking whole texts,
arrays, or objects at a time.
> General purpose input and output procedures, to be able to
read and write easily any kind of file, e.g. a file
containing line numbered lines, an object program file, a
file which was produced by FORTRAN binary output, a disk
directory file etc. etc.
4.3.2.1 FAST, EFFICIENT, POWERFUL AND EASY-TO-USE I/O.
Two procedures INPUT and OUTPUT have been written.
The first argument of INPUT is a reference to an object of
the CLASS infile or directfile, the first argument to OUTPUT
is a reference to an object of the CLASS outfile or
directfile.
Both these procedures can take any number of additional
parameters of any SIMULA type except label, switch or
procedure. The action of OUTPUT is:
**** INTEGER PROCEDURE OUTPUT
INTEGER PROCEDURE OUTPUT returns the number of characters
(over)written in the file. (Including any output produced
which is not directly related to the parameters, e.g. null
characters, null words etc. IF OUTPUT is made on a
DIRECTFILE, it may be important for the user to know how
many lines on the file that are covered by one or several
calls to OUTPUT. He can do this by dividing the sum of the
INTEGERs returned from OUTPUT with (image.length+2) of the
directfile. Such a program will be machine-independent
since OUTPUT returns number of characters.
For parameters of type INTEGER, [LONG]REAL or BOOLEAN: the
value of the parameter is output in such a way that it can
be read by a FORTRAN program. One word (36 bits on the
DECsystem-10) is output. Two words (72 bits) are output for
LONG REALs.
For parameter of type CHARACTER: The internal value is
output. SIMULA systems which pack CHARACTERs in words will
output only the character byte, systems which store
CHARACTERs in full words will output the full word.
For parameters of type TEXT: First the LENGTH of the TEXT
is output in the same way as if it had been given as an
explicit INTEGER parameter to OUTPUT. Then the characters
DECsystem-10 SIMULA Language Handbook, part III Page 48
4.3.2.1 FAST, EFFICIENT, POWERFUL AND EASY-TO-USE I/O.
of the text value are output in internal implementation
dependent format (ASCII-7-bit code packed 5 characters to a
word on the DECsystem-10). If the characters are packed (as
they are on the DECsystem-10) and the last output word is
not full, then it is filled with NULL characters. The
output TEXT value may n o t be preceded by NULL characters
to permit faster output of subtexts. NOTEXT is output as
only the integer LENGTH(=0), and nothing more.
All characters which can be created with the procedure CHAR
can be part of a TEXT which is output with OUTPUT and input
with INPUT, and they should all be returned unchanged after
OUTPUT and a corresponding INPUT.
Note that for subtexts, only the subtext part of the value
is output. If several texts have a common part, the value
is still output completely for each text.
For parameters of kind ARRAY: Each element of the ARRAY is
output just as if it had been a non-array parameter to
OUTPUT. (Even for REF-arrays.) The dimensions and bounds of
the ARRAY are not output.
For parameters of type REF:
All value attributes of the referred object except REF and
REF-array attributes are output just as if these attributes
had been parameters to OUTPUT. REF or REF ARRAY attributes
are not output at all.
OUTPUT may, in an implementation dependent way, output other
descriptive data about the structure of the CLASS to ensure
correct input by INPUT as described below.
If the argument to OUTPUT has the value NONE, then some kind
of indication about this is output.
The order in which the attributes are output is
implementation dependent, and not necessarily the same as
the order in which they are declared in the SIMULA source
program.
Important: If the parameter to OUTPUT is qualified by a
SUPERCLASS (an outer class) of the actual object to which it
refers, then only attributes of the SUPERCLASS are output.
**** INTEGER PROCEDURE INPUT
The INTEGER PROCEDURE INPUT works analogously with OUTPUT so
that anything written with OUTPUT can be read with INPUT.
The INTEGER value returned by INPUT is the number of
characters read (see OUTPUT). If all the data required
could not be read because of end of file, the negated number
of characters that could be read is returned. A call to
INPUT when ENDFILE is already TRUE causes an error
interrupt.
For TEXT parameters, INPUT allocates a new TEXT of
appropriate length using BLANKS and reads the string into
the new TEXT. POS of the new text is set to 1.
DECsystem-10 SIMULA Language Handbook, part III Page 49
4.3.2.1 FAST, EFFICIENT, POWERFUL AND EASY-TO-USE I/O.
For ARRAY parameters: INPUT works just as if INPUT had been
called once for each item in the array.
For REF parameters: INPUT may do a certain amount of
implementation dependent checking for agreement between the
data in the file and the structure of the class to which the
REF parameter refers. Those attributes of the CLASS which
were output with OUTPUT will then be read in. TEXTs will be
allocated with POS = 1 and LENGTH as from the file.
INPUT will only work correctly for REF parameters if the
data at that place in the file was previously written via a
REF parameter to OUTPUT in a SIMULA program, and if the
qualification of CLASS object which was output and the
qualification of the parameter which is input from the same
place in the file agree in the following respects:
i) The order and type of all attributes which are output and
later input agree.
ii) An attribute which was a parameter to the CLASS in
OUTPUT must also be a parameter in INPUT.
iii) If the CLASS has superclasses, then the attributes must
be distributed between the subclasses in the same way.
iv) The number and bounds of the dimensions of ARRAY
attributes must agree.
v) If the argument to OUTPUT had the value NONE, then the
corresponding argument to INPUT must also have the value
NONE.
However, even if the requirements above are not fulfilled,
INPUT is still protected from changing any data in core
except attributes of the CLASS of type INTEGER, REAL, LONG
REAL, CHARACTER or TEXT, which are accessible to the
programmer.
The following characteristics need n o t agree between the
CLASS in INPUT and the CLASS in OUTPUT:
i) The SIMULA source program identifier names of the
attributes.
ii) Number, type, qualification etc. of attributes which
were not output with OUTPUT (e.g. REF or PROCEDURE
attributes).
iii) The executable code in the CLASS.
iv) The structure of such subclasses which were not output
with OUTPUT because of the qualification of the REF
parameter to OUTPUT.
Note that the data OUTPUT with an OUTPUT statements does not
constitute any "logical block". It is therefore possible to
output certain data with "PUT(file,a,b);" and then input the
data with "INPUT(file,a); INPUT(file,b);".
The organisation of files produced by OUTPUT and read by
INPUT should, if reasonably possible, be such that FORTRAN
programs on the same computer can read and write such files.
**** INTEGER PROCEDURE PUTSIZE
To help the programmer avoid overwriting previous
information in a directfile there is an auxiliary INTEGER
PROCEDURE PUTSIZE with the same kind of parameters as
DECsystem-10 SIMULA Language Handbook, part III Page 50
4.3.2.1 FAST, EFFICIENT, POWERFUL AND EASY-TO-USE I/O.
OUTPUT, except for the first parameter (giving the output
file) which need not be given to PUTSIZE. PUTSIZE will
return the same integer as would be returned by OUTPUT if
called with an identical parameter list.
**** BOOLEAN PROCEDURE BYPASS
BOOLEAN PROCEDURE BYPASS(fileref,x) will move the internal
buffer pointer x characters. X may be negative if fileref
is a directfile. If end of file is encountered for an
infile, BYPASS should return TRUE the first time; if called
again a run time error should occur. The first parameter
may refer to any kind of file except a printfile.
**** BOOLEAN PROCEDURE LOOK
There is a further BOOLEAN PROCEDURE LOOK which takes two
parameters, the first a reference to an infile object, the
second of type INTEGER, [LONG] REAL or CHARACTER. LOOK
examines the next word in the input buffer without reading
it. Array parameters are not allowed. Should return TRUE
if end of file is encountered; run time error for the next
call.
LOOK might for example be used to check if a line is line
numbered before reading the line.
COMBINING OUTPUT AND INPUT WITH INIMAGE and OUTIMAGE.
Future versions of DECsystem-10 SIMULA may, because of
standardization work with other SIMULA systems, forbid the
combination of OUTIMAGE and INIMAGE with OUTPUT and INPUT on
the same file. The user is strongly recommended not to use
such a combination.
OUTPUT and INPUT can at your own risk be combined with
OUTIMAGE and INIMAGE on the same file. The file may be
padded with NULLs after OUTIMAGE to a word boundary before
the data written by OUTPUT. OUTPUT and INPUT do not work
through the IMAGE of the file, which is thus not touched in
any way.
For DIRECTFILES, OUTPUT and INPUT will not change the value
of LOC. The first OUTPUT or INPUT after an INIMAGE,
OUTIMAGE or LOCATE will start at the indicated location.
Successive OUTPUTs or INPUTs will start at the place in the
file where the previous OUTPUT or INPUT stopped. A call to
LOCATE preceding OUTPUT or INPUT will cause the OUTPUT/INPUT
operation to start at the indicated position. Note that
this means that an OUTIMAGE immediately after an OUTPUT may
overwrite what was output with the OUTPUT. (Since LOC was
not changed). OUTPUT may overwrite several lines in the
directfile.
OUTPUT and INPUT are allowed on INFILEs, OUTFILEs and
DIRECTFILEs but not on PRINTFILEs.
WARNING!!!! The procedures above have not been approved by
the SIMULA DEVELOPMENT GROUP. If your programs rely on
DECsystem-10 SIMULA Language Handbook, part III Page 51
4.3.2.1 FAST, EFFICIENT, POWERFUL AND EASY-TO-USE I/O.
them, they may be difficult to transfer to SIMULA systems on
other computers than the DECsystem-10. This is especially
true if you combine OUTIMAGE and INIMAGE with OUTPUT and
INPUT on the same file.
4.3.3 FILE HANDLING
**** REF (infile) PROCEDURE FINDINFILE(filespec);
VALUE filespec; TEXT filespec;
**** REF (directfile) PROCEDURE FINDDIRECTFILE(filespec,update);
VALUE filespec, update;
TEXT filespec; BOOLEAN update;
**** REF (outfile) PROCEDURE FINDOUTFILE(filespec);
VALUE filespec;
**** REF (printfile) PROCEDURE FINDPRINTFILE(filespec);
VALUE filespec;
The four procedures findinfile, finddirectfile, findoutfile
and findprintfile are rather similar to the statements "NEW
infile, NEW directfile, NEW outfile, NEW printfile". The
difference is that the value NONE is returned, if such a
file cannot be opened. For directfiles, if the input
parameter update is TRUE, NONE is also returned if such a
file cannot be opened for output.
Reasons why a file cannot be opened may be:
> That an infile does not exist.
> That the file exists, but the file protection system of the
computer does not allow opening.
> For a directfile with update=TRUE or for an outfile: That
you cannot open the file because someone else is updating
it.
If possible, the indicated file is reserved for the user so
that "a:- finddirectfile(....,TRUE); a.open;" will not fail
because someone else opens the file between the two
procedure calls in the example.
Example of use:
FOR D:- finddirectfile("....",TRUE)
WHILE D == NONE DO sleep(10);
Will sleep until the directfile is updateable.
**** BOOLEAN PROCEDURE SCRATCHFILE(filespec);
VALUE filespec; TEXT filespec;
If the file indicated by filespec exists and the program is
allowed to delete (scratch) it, the file is deleted
(scratched). The result is TRUE if a file could be deleted,
FALSE if no file could be deleted. Delete (scratch) implies
removing the file so that it becomes inaccessible to this
and other programs on the computer.
DECsystem-10 SIMULA Language Handbook, part III Page 52
4.3.3 FILE HANDLING
**** PROCEDURE CLOSEOPEN(f); REF (file) f;
INSPECT f DO
BEGIN TEXT t;
t:- image; close; open(t);
END;
**** BOOLEAN PROCEDURE DOTYPEOUT(tty); REF (outfile) tty;
COMMENT
IF tty == conversational terminal AND
the conversational user has inhibited output temporarily
at his terminal AND
the computer can restart typeout to the terminal
THEN restart this typeout, beginning with the
next outimage or breakoutimage;
COMMENT on the DECsystem-10, the CTRL-O bit is reset;
**** INTEGER PROCEDURE LASTLOC(df); REF (directfile) df;
Lastloc returns the highest location of any image which has
been written in the directfile during this or any previous
use of the file. Lastloc returns -1 when the directfile is
not open.
**** INTEGER PROCEDURE MAXLOC(df); REF (directfile) df;
Maxloc returns the largest integer such that
"locate(maxloc); outimage;" will not cause any error
interrupt of the program.
**** INTEGER PROCEDURE TRMOP(funcod, iox, val);
INTEGER funcod, val; REF (Outfile) iox;
TRMOP allows the SIMULA program to test and change the
values of certain status items associated with a terminal
connected to the SIMULA program via a file object. The
program can thus achieve the equivalents of the monitor
commands .TTY NO ECHO, .TTY LC etc.
Funcod is the four-digit octal code for the function to be
performed.
A first digit = 0 signifies a special function (usually a
generalization of the TTCALL UUO for the job-controlling
terminal).
If the first digit is 1, a read function is performed, i. e.
the current value of the field is returned as function
value.
If the first digit is 2, the corresponding value is set to
the value given by val, and the old value is returned as
function value.
The effect of other values of the first digit is
installation dependent.
If the requested function cannot be performed, the value of
the TRMOP function is -1.
Iox is an outfile referring to the TTY involved. Iox==NONE
refers to the terminal controlling the job.
Val is the new value for the status item. Redundant except
for set function (funcod=8R2xxx).
DECsystem-10 SIMULA Language Handbook, part III Page 53
4.3.3 FILE HANDLING
Trmop returns the old value of the status item when
relevant.
Special case: for funcod = 1 or 2, a skip return is mapped
as the function value 1, non-skip return as 0.
Example I: "trmop(8R1003,sysout,0)" returns 1 if the
previous setting was "TTY NO LC", returns 0 if the previous
setting was "TTY LC". (TTY NO LC means that the monitor
converts all lower case letters to upper case in
transmissions from the conversational terminal.)
Example II: "trmop(8R2003,sysout,1)" is equivalent to the
monitor command "TTY NO LC".
All the status items which can be interrogated or set by
trmop are listed in the DECsystem-10 Software Notebooks,
"DECsystem-10 monitor calls", section 5.10.7. Here is an
excerpt of the most useful items:
funcod value
8R1003 1 = NO LC (lower case)
8R1006 0 = NO TAB (tabs converted to multiple spaces)
8R1007 1 = NO ECHO (printable characters not echoed)
8R1010 1 = NO CRLF (monitor inserts no extra CR-LFs)
8R1011 Horizontal position of carriage
8R1012 Carriage width (TTY WIDTH)
8R1013 1 = NO GAG (accepts external messages)
8R1017 TTY FILL (filler class index, governs number of fill
chars after FF and CR)
8R1024 Number of lines output on this page
8R1026 0 = ASCII codes 175 and 176 converted to altmode
DECsystem-10 SIMULA Language Handbook, part III Page 54
4.4 CONTROLLED ERROR HANDLING.
4.4 CONTROLLED ERROR HANDLING.
See also the procedures SCANREAL, SCANINT and SCANFRAC in
chapter 5 of this handbook for control of bad data errors.
The procedures MASKERROR, SENSEERROR, JUMPERROR and
RESETERROR described below have not yet been implemented,
and no promise is made about if or when to implement them.
4.4.1 GENERAL-PURPOSE ERROR CONTROL PROCEDURES [NOT READY]
BY STEFAN ARNBORG AUGUST 1975, MODIFIED OCTOBER 1975
Problem.
Dependable software must be prepared to detect and diagnose
errors in input data. For complex problems error handling
will take a significant part of the programming effort.
Programmed error handling is a means to achieve error
handling without having to reprogram in SIMULA checks
actually made by the programming system and the hardware.
The absence of this facility has been used as one argument
for using PL/1 rather than SIMULA at FOA.
Solutions.
Programmed error handling in other programming systems and
environment usually falls in one of three classes:
A Implicit action.
In CDC Algol an error may cause a jump to a preset label.
In the Knuth proposal for I/O in Algol 60, errors may cause
predefined procedures to be called. In PL/1 an error may
cause a previously set ON-unit to be activated.
B Error returns.
The READ/WRITE statements of many FORTRAN implementations
permit error and end-of-file exit labels to be passed as
parameters. Many general-purpose algorithms in ACM
collected algorithms have parameters returning error codes
or error exit label parameters.
C Raising flags.
In the CODASYL DBMS proposal, an error condition raises
flags that can be inspected by the program.
DECsystem-10 SIMULA Language Handbook, part III Page 55
4.4.1 GENERAL-PURPOSE ERROR CONTROL PROCEDURES
Choice of solution for SIMULA.
The following requirements on a solution are rather obvious:
i) Existing programs should not be affected unless the
user wants to take advantage of the facility.
ii) It must be easily implemented on existing systems.
iii) It must be well defined and easy to use.
iv) It must be compatible with the overall language
philosophy.
v) In particular, it must be as implementation independent
as possible.
Method A seems to satisfy i) and v) but contradicts the
other requirements. In particular, it requires much
programming effort (at least in the IBM 360 and DEC 10
implementations) to be able to enter a user program point
from anywhere in the run-time system. However, an implicit
jump is easier to implement than an implicit procedure
call.It has the slight drawback that it is difficult to know
where the error occurred and to proceed after corrections,
because bookkeeping operations like e.g. file positioning
may get out of phase. It is also not agreed that implicit
actions are consistent with good programming methodology.
Method B contradicts i) or ii) and iv) depending on whether
the additional parameters are made compulsory or optional.
Moreover, it takes care only of errors in system procedures.
Method C complies with all requirements to a reasonable
degree. However, it requires a program to continue after an
error has occurred and this continued execution will maybe
not be entirely implementation independent. It can be seen
as a method to achieve an orderly failure rather than a
means to implement a complicated polyalgorithm. It is easy
to implement recovery procedures of differing levels of
detail as in the example:
BEGIN initializesequenceofbatches;
WHILE morebatches DO
BEGIN
processbatch:
WHILE morerecords DO
BEGIN processrecord:
WHILE morefields DO
BEGIN processfield;
recovery1;
END;
recovery2;
END;
recovery3;
END;
END;
DECsystem-10 SIMULA Language Handbook, part III Page 56
4.4.1 GENERAL-PURPOSE ERROR CONTROL PROCEDURES
At each of the recovery points it is possible to prevent
upward updates from an erroneuos field, record or batch.
Proposal.
It is suggested that the following text be inserted into the
SDG publications:
"Programmed Error Handling.
The programmed error handling facilities of SIMULA make it
possible to achieve, in a SIMULA program, an orderly
handling of certain errors occurring during execution as a
result of incorrect or unexpected inputs to the program.
Errors are classified into the following categories:
1 Underflow in floating point computation
2 Overflow in computation or division by zero
3 I/O transmission error
4 End of file error
5 Edit overflow
6 Incorrect text contents for de-editing procedure
7 Array index out of range
8 Incorrect parameter to mathematical function
9 Time limit - as defined by a previous call to TIMELIMIT
- exceeded.
10. All the errors listed above.
999999 Remaining errors that can be intercepted in an
implementation.
The errors above are not all errors that can result from
incorrect data but only those that will occur as a direct
and immediate consequence of invalid data. Second order
errors result from following an incorrect path of the
program because of invalid data: those errors are not
handled.
The following system procedures are available for error
handling:
[Addition by Jacob Palme 1976-03] Possibly we could allow an
implementation to add an implementation dependent number of
extra error codes, between 11 and 999998. The error code
999999 would then be equivalent to all such error codes,
which means that programs using only error codes 1-8 will
still be machine independent and programs using error codes
9, 10 and 999999 will be reasonably machine independent,
while programs using extra error codes between 11 and 999998
will at their own risk be machine dependent.
**** procedure MASKERROR(CODE,COUNT); integer CODE,COUNT;
comment Execution of MASKERROR permits COUNT errors of
category CODE to occur without intervention by the run time
system. The effect of continuing after an error is
dependent on the kind of error: (On certain computers, the
architecture may make these default effects impossible. If
so, they may do otherwise.)
DECsystem-10 SIMULA Language Handbook, part III Page 57
4.4.1 GENERAL-PURPOSE ERROR CONTROL PROCEDURES
1. Result of operation is zero.
2. Result of operation is zero.
3. The image fetched will contain the record as
transmitted, if possible. Otherwise a blank image will
be fetched.
4. The image will be set to blanks. ENDFILE will still be
TRUE if sensed.
5. The field of the operation will contain asterisks.
6. The result will be zero.
7. The first acceptable index (i e the lower bound) will be
used. Note that on some implementations the first
ELEMENT (lower bound everywhere!) may have to be used.
8. The result of the function will be zero.
9. No action, job continues.
999. Implementation dependent.
A new call to MASKERROR resets the previous error count (as
returned by SENSEERROR).
If an implementation enters dialog or debug mode in case of
an error of a category mentioned above, this facility will
be suppressed by a call to MASKERROR for the category.
When the program starts, categories 1 and 5 are
automatically masked by the SIMULA system with a large value
on COUNT.
;
**** procedure JUMPERROR(CODE,L);integer CODE;label L;
comment Execution of JUMPERROR directs the run time system
to make an implicit jump to L if an error of category CODE
occurs.The sequence of operations is interrupted so that no
effect of the illegal operation remains when L is entered,
nor will it be possible to find out exactly which operation
caused the error, except indirectly from the contents of
program variables.
The label L must be in the outermost block of the main
program (recovery for the outerwise possible ILLEGAL GOTO
may be very difficult or impossible to implement). From
this follows that JUMPERROR cannot be called in a separately
compiled module. A call to jumperror for other labels than
in the outermost block should cause an error interrupt.
Both MASKERROR and JUMPERROR can be called for an error
category, but the last call has effect.
DECsystem-10 SIMULA Language Handbook, part III Page 58
4.4.1 GENERAL-PURPOSE ERROR CONTROL PROCEDURES
Dialog and debug mode recoveries are suppressed by JUMPERROR
as by MASKERROR.
;
**** procedure RESETERROR(CODE); integer CODE;
comment Execution of RESETERROR inhibits the effect of
previous calls to MASKERROR or JUMPERROR for the category
CODE. Subsequent errors are intercepted and diagnosed.
;
**** integer procedure SENSEERROR(CODE);integer CODE;
comment A call to SENSEERROR returns the number of errors of
category CODE that have occurred. If CODE is zero, the
total number of errors is returned. SENSEERROR does not
reset the error counts.
; "
Discussion.
This proposal was modified at in october 75 after the SDG
meeting. The proposal can be modified in several areas to
accomplish a different balance between implementability and
implementation independence:
The error categories can be made finer or coarser, in
particular the existence of category 999 is debatable;
Default settings can be altered;
One may redefine results of undefined operations;
One may specify the error categories by reference to the
sections in the Common Base or Algol report where the error
is described;
It is possible to use different system procedures instead of
having the non-natural assignment of codes to error
categories;
These questions are best solved (if the proposal is
accepted) in the Simula Development Group.
DECsystem-10 SIMULA Language Handbook, part III Page 59
4.4.2 ERROR INTERRUPT ROUTINES
4.4.2 ERROR INTERRUPT ROUTINES
**** PROCEDURE enterdebug(maycontinue); BOOLEAN maycontinue;
COMMENT the debugging system is entered. If maycontinue is
TRUE, execution of the SIMULA program is allowed to resume
after the debugging session.
**** PROCEDURE abort(message); VALUE message; TEXT message;
BEGIN
IF message =/= NOTEXT THEN
BEGIN
outimage;
outtext(
"EXECUTION TERMINATED DUE TO CALL OF ERROR PROCEDURE");
outimage;
outtext("MESSAGE: "); outtext(message); outimage;
END;
enterdebug(FALSE);
END;
Implementations are recommended to use the procedure abort
for error exits from utility procedures in the external
utility procedure library.
**** PROCEDURE FORSIM(n); INTEGER n;
FORTRAN subroutines called from SIMULA are not allowed to do
i/o or otherwise access the FORTRAN high segment, since
SIMULA requires the SIMULA high segment. If you want to use
a FORTRAN subroutine which uses facilities in the FORTRAN
high segment